[lkml]   [2001]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:08    [W:0.065 / U:1.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site