Re: How to check the kernel compile options ?

[Mike Touloumtzis <miket@bluemug.com>]

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