Messages in this thread | | | Date | Mon, 22 Oct 2001 05:34:43 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] binfmt_misc.c, kernel-2.4.12 |
| |
On Mon, 22 Oct 2001, Keith Owens wrote:
> >Erm... Keith, I might be misreading the source, but... Shouldn't the > >information like "block major $FOO is in module $BAR" live in > >/lib/modules/*/* ? > > Historically the mapping of device majors to module or binary format > type to module was coded into modutils, via util/alias.h. That was a > mistake, it should have used the same technique as pci, isapnp, parport > etc., each module has a table that defines what it handles and modutils > extracts the data directly from the modules. Developers have changed > the names of their modules and now we have hard coded module names in > modutils that do not match the names used by some kernels. Hindsight > is wonderful! > > In modutils 2.5 I will get rid of all the hard coded entries in > util/alias.h. Instead each module will define what it supports, > including any special commands to be run when the module is loaded or > unloaded. Much easier for everyone and far more flexible.
Heh. OK, so you've stopped me in the middle of writing RFC that proposes addition of MODULE_CONF(string) that would put that string into separate section and making modules_install dump these sections, feed them through s/_NAME_/`basename $module`/ and cat them into defaults file that would go into $INSTALL_MOD_PATH. MODULES_BLKDEV(), MODULE_LDISC(), etc. would be trivial wrappers around that.
Looks like the thing you mentioned would make quite a few people happy. Might be worth doing in 2.4...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |