Date: Sun, 30 Mar 1997 12:35:45 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <Pine.BSF.3.95q.970330115909.6939A-100000@kipper.nlsystems.com> In-Reply-To: <19165.859719100@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Mar 1997, Jordan K. Hubbard wrote:
> 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?
The isa_device structures (for statically linked devices) will still be
static but they will not be compiled into the driver. The important idea
to get across here is the difference between device instances (isa_device)
and device drivers (isa_driver). For your SMC card, you would include the
'ed' driver module and add an instance ed0 with the right flags.
The changes to the way isa works today would be pretty small. Instead of
the isa_device referencing the driver by pointer:
{ 7, &wdcdriver, IO_WD1, IRQ14, -1, C 0x00000, 0, wdintr, 0,
0x0000, 0, 0, 0, 0, 1, 0, 0 },
the reference would be by name:
{ 7, "wdc", IO_WD1, IRQ14, -1, C 0x00000, 0, 0,
0x0000, 0, 0, 0, 0, 1, 0, 0 },
When the kernel boots, the wdc module would call a function in isa, say
isa_register_driver() to tell it how to handle instances of type "wdc":
...
isa_register_driver("wdc", &wdcdriver, wdintr);
...
Then isa will match devices to drivers using the names and everything else
will work as it does today. UserConfig should be able to edit the device
instances just as easily as it does now.
For adding devices dynamically, a new system call would create an
isa_device structure and fill it with the new device's config data (io,
irq, flags etc.) The new device will then match against the installed
drivers by name as for static devices. The commands used might be
something like:
# Add a new device using ed driver
isaconf -a ed0 port=0x280 irq=5 iomem=0xd8000 flags=4
# Load the ed driver to activate all ed* instances
modload /lkm/devs/isa/ed.so
>
> 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 ...
I think that 'sysctl on steroids' would be a very good place to put this
information. With a persistent sysctl system, you would place templates
for all the isa device instances that you want in the sysctl database and
when the system boots (or when sysctl is used to edit the instances).
This kind of support is not required, given that we can compile in the
device instances using config(8) or add new ones using isaconf(8).
>
> 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
I don't want to go overboard with adding features to modload. Ideally,
modload should just dump a new object into the kernel run any init code
which it contains. Intelligence about particular classes of module
belongs in specific utilities which was the reason for wanting an
isaconf(8) utility.
>
> 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 ]
That would be nice. I think we can do that last though :-). I
>
> 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!
I am definately going to do this, in some form at least. My ultimate aim
is to be able to have a minimal kernel which can automatically load the
drivers that it needs as it boots. I would like to get at least a sketch
of a design and some consensus before I actually start coding though.
> P.S. Nonlinear Systems, eh? Do tell! :-)
>
My new company! Actually, its just me and my computer at the moment ;-).
--
Doug Rabson Mail: dfr@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970330115909.6939A-100000>