Messages in this thread | | | Date | Thu, 7 Feb 2002 13:41:45 -0800 | Subject | Re: How to check the kernel compile options ? | From | Mike Touloumtzis <> |
| |
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/
| |