[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Kernel module framework status?
On May 2, 9:48am, Anders Magnusson wrote:
} I'm trying to find some documentation of the status of the kernel
} modules, but only finds some scattered postings.
} What is done, what is left, are there any decision points etc...?
Paul Goyette has been making great strides on modularising
I have a couple of projects in the back of my mind for the
module framework, such as being able to load <module>.plist at boot
time, and being able to control when modules are loaded during the
the boot process. The idea is that things like the pciverbose
module might want to load before autoconf whereas a disk driver
might want to load after autoconf but before findroot.
There is also the idea of having a module specify the device(s)
it handles by vendor:product so that autoconf can simply hunt for
a module that way instead of having to know the name of the device.
Jared McNeill had some prototype code for this years ago, and I
probably have a copy of it somewhere.
Then there is the whole thing that core put out a few years
ago about packaging kernels with the corresponding module.
Long term I would like to see some kind of KABI so that modules
aren't so closely tied to a particular kernel. But, this is
definitely a long term project/goal.
Another nice thing to have would be a way to specify a schema
for a <module>.plist file to specify the options that a particular
module takes. Then a proper editor could be created for editing
<module>.plist files. Note that putting stuff in a <module>.plist
file that the module doesn't understand isn't likely to cause any
harm as it would likely just be ignored. However, if you misspell an
option, the module might not behave the way you expected.
}-- End of excerpt from Anders Magnusson
Main Index |
Thread Index |