Date: Sun, 30 Mar 1997 02:51:40 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Doug Rabson <dfr@nlsystems.com> Cc: current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <19165.859719100@time.cdrom.com> In-Reply-To: Your message of "Sun, 30 Mar 1997 10:25:38 %2B0100." <Pine.BSF.3.95q.970330101633.1828A-100000@kipper.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
What can I say? I hate it. No, no, I'm just kidding! :-) It looks like a fabulous system, of course. Where do I sign up? :) Some questions, of course: How do you see an LKM (or whatever you're going to call objects in this new system - DRMs? Doug Rabson Modules? :-) accessing configuration data? To be more specific, take the existing system we have right now with UserConfig: Because all the isa_device structures are static, we can get in there and pound on them before the bus probing code is run and we can leave lots of little hints for a driver in the process. To be sure, a lot of the enable/disable behavior will become redundant in a truly dynamic system such as yours, but there are still issues which won't go away quite as easily. One good example is the test machine sitting a few feet to my right - it has an early SMC Ether16 card in it which needs the flags value set to 0x4 on ed0 before it will probe as a 16 bit card. There's no way the driver could know this, the card is simply braindead and I need to tell it. And that's just one example - I'm sure there are many others. There are and will be drivers that have ordering issues and need to be probed before or after other drivers - how will search order that be specified? My feeling is that this could be handled by a more general configuration space (sysctl on steroids, something phk has also been thinking about) where static drivers can register callbacks for named properties, e.g. "my name is sys.dev.fred_driver and I'd like to store my foo_flags property here." Each property would have a stringToData() and dataToString() function pointer and sizeof(void *) bytes of data to use however the conversion functions saw fit so you could come up with more complex representations for things as needed (lists, floats, etc). Then you use sysctl to do something like the following for dynamic drivers: sysctl -w sys.devs.ed0.flags=0x4 dfrmodload /lkm/devs/ed0.lkm ifconfig ed0 ... The code in ed0.lkm knows its unique path is sys.devs.ed0 so it knows where to find the "flags" property and can do the right thing with it. I also don't see any reason why you couldn't just collapse the functionality into "dfrmodload" (:-) and say something like this: dfrmodload sys.devs.ed0.flags=0x4 /lkm/devs/ed0.lkm Though there's also something to be said for the conceptual elegance of: sysctl -Pw sys.devs.ed0.flags=0x4 ifconfig ed0 ... [ dynamically loads ed0 lkm on first ref ] Heh heh. :) That's just off the top of my head and I'm sure other issues will come to me in the day/night, as I'm trying to sleep.. :) Seriously, this pretty much looks like the module system we've always wanted and I'd love to see you do it. Like I said, sign me up! Jordan P.S. Nonlinear Systems, eh? Do tell! :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19165.859719100>