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