tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MODULE_CLASS_DRIVER and locators stuff
On Sat, 3 May 2008 15:37:28 +0100
Andrew Doran <ad%netbsd.org@localhost> wrote:
> I have a couple of problems with the approach:
>
> First I think we'd be falling into the LKM trap by putting a bunch of
> class specific code into the module system. :-). I think that it doesn't
> belong there: as I see it, all the module framework really needs to do is
> get the module loaded, linked and call its mi_modcmd() routine so that it
> can get itself noticed by the rest of the kernel. I think that the driver
> attachment code should belong to autoconf, not kern_module.c.
I agree, I need to investigate how to improve this situation.
> Second, you can build modules into the kernel and they operate mostly like
> loadables. There shouldn't be a need for seperate wrapper code under
> sys/modules. The ideal solution would be a Makefile under modules/auhci
> that pulls in the existing sources and does nothing else. You can do this
> with file systems already, for built-in drivers we probably need a
> module_init_class(MODULE_CLASS_DRIVER) somewhere in or around configure(),
> so that they're available at the right time.
I wondered wtf was module_init_class() and I saw it in vfs_init.c, and I
thought that we'd need it at some point...
I agree here too, my goal is to do something like FreeBSD: add a macro in
the driver's souce and only require the Makefile to build the module...
but I'm not there yet :-)
> So the idea is that drivers would link into the system the same way,
> irrepective of whether or not they were built into the kernel. Problems:
>
> - Autoconf already has an way to establish drivers, linking them into
> tables etc. We already have the cfattach data and so on. Problem because
> it's also the way that we get the object code into the kernel in the
> first place.
>
> - When loading drivers from the file system, we probably want to pick up
> a prop dictionary that contains locators / options etc. If a driver
> is built into the kernel, that info already exists in another form.
>
> We could add a flag for config(1) that indicates that a particular driver
> is modular and will register itself, but what would you do about
> locators? I don't have good ideas at this point.
Ok. I'm not sure how to handle the locators stuff yet.
--
Juan Romero Pardines - xtraeme at gmail|netbsd dot org
The NetBSD Project
Make your own NetBSD/x86 Live CD:
http://www.netbsd.org/~xtraeme/mklivecd/
Home |
Main Index |
Thread Index |
Old Index