On Thu, Feb 07, 2002 at 10:08:44PM +0100, Daniel Phillips wrote:
> On February 7, 2002 09:34 pm, Mike Touloumtzis wrote:
> > A final argument for using packaging/bundling tools and userspace files
> > instead of files in /proc for tracking kernel metadata:
> >
> > -- Kernels are no longer single files, at least for most people.
> > A _harder_ problem than this one is tracking which modules go with
> > which kernel. Solving this problem solves the configuration tracking
> > problem as a _side_effect_. Conversely, solving the configuration
> > tracking problem without solving the module tracking problem is
> > largely useless.
>
> I can always rebuild the modules from a standard source tree, given the
> config. This makes the config a far more important piece of data than the
> modules themselves, and that is why I want it stuck right on the side of the
> kernel, the way my memory sticks have a little sticker on them telling me
> what I've got.
>
> As an option of course, you're welcome to build your kernel without it, and
> you can also peel the stickers off your memory sticks and file them in a
> drawer if you like.
OK, this is getting a little silly, and I don't have many new arguments
to make, so I'll just respond once. Feel free to have the last word :-).
Peeling information off memory sticks would be silly. It's already _on_
them memory, and it costs nothing to leave it there. Moreover, if you're
using a packaging system, putting config info in the package is precisely
analogous to attaching an informative sticker to the kernel.
Adding configuration information to the kernel is a change to the status
quo, and has a cost. The cost is small, but I'm unsympathetic to that
argument because many small convenience features, each with a small cost,
add up to a large cost.
You appear to be justifying a change to the kernel status quo with the
argument "it is a useful feature for some people, so it should go in".
I agree that it's useful for some people, but I feel that the kernel
should hold to a higher standard for feature inclusion: "It's a useful
feature for some people, and it is impossible or impractical to implement
it well in userspace." Even esoteric drivers meet my test; IMHO the
inclusion of configuration files in the kernel does not.
My contention is that not only is it _possible_ to implement a solution
in userspace (which alone should be enough), but that a userspace solution
is _already implemented and widely used_, and that moreover I am perfectly
happy using it. I don't see why that shouldn't be the kiss of death for
adding a new feature to the kernel.
miket
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:01:07 EST