Re: Building .config into the kernel

Michael Meissner (meissner@cygnus.com)
Thu, 14 Jan 1999 14:08:56 -0500


On Thu, Jan 14, 1999 at 10:04:47AM -0600, Mitchell Blank Jr wrote:
> Oliver Xymoron wrote:
> > Trouble is, that doesn't patch cleanly. Redhat distributes patches
> > along with pristine source in the SRPMs, allowing you to upgrade the
> > source and still use the patches. If you have multiple patches fighting
> > over the EXTRAVERSION line, or Linus decides to remove it after the
> > -pre series, you get rejects.
>
> Have one of the patchs in the SRPM just update the EXTRAVERSION line.
>
> As someone already pointed out, people who build their own kernel (either
> from .tar.bz2 or by playing RPM games) probably know what is in their
> kernel and can report it themselves. The biggest need is differentiating
> between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...

First of all, I recall we had this discussion about year ago, and Linus turned
it down as kernel bloat. We even had people thinking about putting the .config
file in another section of the zImage file that wouldn't get loaded.

However, I would challenge your assumption that people know what is in their
kernel. Like a lot of us, I build my own kernels, etc. But I'm continually
tinkering with it. Maybe I built it without masquerade support because I
wasn't using it at the time (or because it was 2.2.0-pre5 to use a recent
example, and it didn't build with masquerade enabled). Particularly as you go
to earlier kernels that I've saved in my /boot partition. Lets see, I have 8
different versions in there right now, along with a tar'ved version of the
appropriate modules directory that I can untar in a flash if need be, and I
have 2-3 floppies sitting around the office with a kernel, lilo, and the tar'ed
and gzip'ed module directory for fast booting.

My personal vote would be to have a sed script eliminate all of the 'no'
answers in the .config file and the 'CONFIG_' prefix, convert it into a large
string, compile it, and then print it out in /proc/version after the version #
line (and of course break a whole new round of badly written /proc munging
programs, but that seems to be a Linux tradition).

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/