Date: Mon, 2 Aug 1999 20:25:34 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Warner Losh <imp@village.org>, Juha.Nurmela@quicknet.inet.fi, Chris Costello <chris@calldei.com>, hackers@freebsd.org Subject: Re: Proposing argv for klds and preloaded modules Message-ID: <Pine.BSF.4.10.9908022024390.385-100000@salmon.nlsystems.com> In-Reply-To: <37A5D5DC.30CC6BE2@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Aug 1999, Daniel C. Sobral wrote: > 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? I'm currently extremely distracted by non-FreeBSD work and will be so until after SIGGRAPH. If Peter doesn't show an interest before then remind me in a couple of weeks. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.10.9908022024390.385-100000>