public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] binfmt_misc.c, kernel-2.4.12
Date: Mon, 22 Oct 2001 11:56:32 -0400	[thread overview]
Message-ID: <200110221556.f9MFuWH15850@deathstar.prodigy.com> (raw)
In-Reply-To: <24947.1003742395@ocs3.intra.ocs.com.au>

In article <24947.1003742395@ocs3.intra.ocs.com.au> kaos@ocs.com.au wrote:

| 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!

  Not to mention the recent surge of renaming the parameters of modules
for no obvious reason... The number of conditionals in modules.conf is
getting pretty large for people who need to run multiple kernels until
the release of one which fixes all the bugs.

| 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.

  I'm not sure about flexible, does it matter where the parameters or
commands are built-in as long as the admin has to change source code
instead of config files to change it? It just seems like a really poor
approach to what has been very flexible.

-- 
bill davidsen <davidsen@tmr.com>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.

  parent reply	other threads:[~2001-10-22 15:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-19 11:54 [PATCH] binfmt_misc.c, kernel-2.4.12 Albert Bartoszko
2001-10-19 12:54 ` Alexander Viro
2001-10-19 13:32   ` Richard Guenther
2001-10-19 18:48     ` Alexander Viro
2001-10-19 21:35       ` Richard Guenther
2001-10-19 22:00         ` Alexander Viro
2001-10-22  6:00   ` Albert Bartoszko
2001-10-22  6:47     ` Alexander Viro
2001-10-22  7:42       ` Keith Owens
2001-10-22  8:05         ` Alexander Viro
2001-10-22  8:21           ` Keith Owens
2001-10-22  8:33             ` Alexander Viro
2001-10-22  9:19               ` Keith Owens
2001-10-22  9:34                 ` Alexander Viro
2001-10-22  9:55                   ` Alexander Viro
2001-10-22 11:17                   ` Keith Owens
2001-10-22 11:33                     ` Alexander Viro
2001-10-22 11:52                       ` Keith Owens
2001-10-22 12:15                         ` Alexander Viro
2001-10-22 12:37                           ` Keith Owens
2001-10-22 15:56                 ` bill davidsen [this message]
2001-10-22 15:47             ` bill davidsen
2001-10-22 17:24       ` Andrew Morton
2001-10-22 17:50         ` Alexander Viro
2001-10-23  9:28       ` Albert Bartoszko
2001-10-21 15:26 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200110221556.f9MFuWH15850@deathstar.prodigy.com \
    --to=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox