On Tue, 2010-03-02 at 19:55 +0200, Ozan Çağlayan wrote:
> Jon Masters wrote:
> > On Thu, 2010-02-25 at 17:11 +0000, Alan Jenkins wrote:
> >
> >> Next on my list was a prototype I started to make Andreas' softdep code
> >> a bit simpler.
> >
> > Don't worry too much about my other mail, I see the three softdep
> > branches in your tree - I fetched them to take a look. More doc cleanups
> > in the dev branch now, and a fix for the locking problem coming shortly.
>
> Offtopic: Is there any doc/webpage/README about "what a softdep is?" somewhere?
So you never really got a good answer. Sorry about that, I'm busy doing
lots of cleanup work at the moment and getting things more organized.
Anyway, the point behind softdeps is to express dependencies that are
not otherwise explicit through the modpost scripts and depmod figuring
out one module should load before another. Think of e.g. some module
providing optional sysctls, a sound synth module not directly required
but basically very useful when you load core sound pieces, etc. These
are just abstract examples of the kinds of hints that might happen.
In modprobe, one of the problems we have had for years are the "install"
and "remove" commands in the configuration files. These are just two of
the things I plan to kill off a general need for (take a look at the
options that modprobe supports and you'll see other candidates - I've
started to make some notes in the sources and mention in the man pages),
starting with deprecating the kind of cases where you do things like the
following the following just to pull in another module:
install some_module /sbin/modprobe --first-time --ignore-install
some_module && { /sbin/modprobe something_else; /bin/true; }
We rather prefer that modules can hint that another module should be
loaded as a soft dependency for it, even though no explicit symbol
dependency exists, or at least that there is a configuration file entry
that states this. So in a perfect world, there would be a combination of
modules providing direct hints themselves, and configuration file
entries replacing the general abuse of "install" over the years.
NOTE: There is in-kernel support for requesting modules too (and the
kernel can call out to load them - this is in addition to the existing
combo of uevent emission on load followed by udev calling modprobe to
pull in e.g. drivers for devices on a bus), but that isn't the solution
either and fewer modules are needing to do that over time. There's no
need to programatically call out to load soft dependencies.
Another benefit is that mkinitrd/mkinitramfs/whatever needs to determine
which modules to pull into the initrd/initramfs. If we have to dump the
modprobe config and parse out the semantics of "install" commands (which
we do have to today in some cases), we have already lost. Instead, it
should be easy to dump out all dependencies without using "install".
I should have some docs up on the wiki soon, and I am working on the
merge of these as well as my other cleanups. As I mentioned, general
crap will go into -dev before it goes into master after testing.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
