Date: Tue, 03 Aug 1999 02:31:08 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Warner Losh <imp@village.org> Cc: Juha.Nurmela@quicknet.inet.fi, Chris Costello <chris@calldei.com>, hackers@FreeBSD.ORG Subject: Re: Proposing argv for klds and preloaded modules Message-ID: <37A5D5DC.30CC6BE2@newsguy.com> References: <37A5C680.3CA1DBD2@newsguy.com> <Pine.BSF.4.05.9908020021290.9676-100000@pena.oh5nxo.ampr.org> <199908020442.WAA01145@harmony.village.org> <199908021644.KAA06858@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > > In message <37A5C680.3CA1DBD2@newsguy.com> "Daniel C. Sobral" writes: > : Modules are not just drivers. Forget about drivers, and try again. > : :-) > > But the generic mechanism extends beyond just drivers :-) Ah, I recall now. Something similar to the way X works, with all the information stored in a file instead of passed on the command line. If things are passed on the command line, we put a getopt() in the kernel and that's that. Get the _string_ to the application, and let it do it's job. We'll seriously regret anything else. For that matter, when I was working on loader's commands, I want to pre-process their arguments. That idea was shot down on the grounds that we can't foresee what the applications will need as parameters. The same applies here, right? So, here is my take. On one hand, we have Juha's code. The change proposed needs a new syscall. The sooner we make the change, assuming we are making it at all, the less pain. It provides a way of getting parameters that is compatible with what is already possible with loader (ie, the module need not differentiate between it's method of loading). The code is working and ready. On the other hand, we have a vaguely defined vapourware that looks real cool, and will be done some day after other outstanding priorities are dealt with. I'm not a fan of adding code to FreeBSD just because it exists. That _is_ one thing we do different from another popular open source OS, and which serves us well. If the code is crass, does not serve us well, is kitchen-sink bloating, or goes in a direction we see as a dead-end, it should not be imported. Alas, it seems none of the above applies. Even if we *do* come up with something better later, this code won't get in the way any more than what's in loader(8) already does. In that light, I think we ought to import it into our tree. BTW, won't any of the kld gods speak up? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37A5D5DC.30CC6BE2>