Re: How to check the kernel compile options ?

Re: How to check the kernel compile options ?

[Andries.Brouwer]

    > I would be surprised if there is anyone on this list
    > who has not lost at some point either the .config, the
    > ksyms, or something similar associated with at least
    > one build they've made.

    Sure.  And people have lost their root filesystems due to "rm -rf /".
    That doesn't mean we build the entire (real) root filesystem into
    the kernel.

	-hpa

Peter, in my eyes this is an unreasonable answer.

For debugging and other purposes it is good to have some
information. One may wish to know about a certain kernel image
what Linux kernel version that was, with what patches, compiled
with what options, by which compiler. Or one may want to know
such things about the currently running kernel. Even user-space
programs (like mount) may want to know (what NFS version? do we
have CONFIG_JOLIET?).

Today we supply a little of this information.
For example, /proc/version supplies information on version
and compiler and date. Why? One might as well keep this compiler
info in a separate file. What a waste of unswappable kernel memory!

You see - this is not a matter of absolutes.
In the good old days, when an operating system had to fit in 4k
and a device driver in 128 words, putting a 100-char text like
the one found in /proc/version into the system would be ridiculous.
Today nobody worries about a hundred bytes paid for some useful info.

So, the question is: how useful is the information, and how expensive
is it to store it. Consider the config options. How much space do they
take? Typically 1-5 kB (compressed). If this is stored at the end of
a kernel image file, and not loaded into memory, then the kernel memory
cost is zero. If this is made part of the kernel itself, say accessible
via /proc, then the cost is 1-5 kB.

So, you should ponder whether it is worthwhile to pay this cost of zero,
and ponder whether it is worthwhile to pay this cost of 5 kB.

Andries

Re: How to check the kernel compile options ?

[Ian S. Nelson]

Andries.Brouwer@cwi.nl wrote:

>    > I would be surprised if there is anyone on this list
>    > who has not lost at some point either the .config, the
>    > ksyms, or something similar associated with at least
>    > one build they've made.
>
>    Sure.  And people have lost their root filesystems due to "rm -rf /".
>    That doesn't mean we build the entire (real) root filesystem into
>    the kernel.
>
>	-hpa
>
>Peter, in my eyes this is an unreasonable answer.
>
>For debugging and other purposes it is good to have some
>information. One may wish to know about a certain kernel image
>what Linux kernel version that was, with what patches, compiled
>with what options, by which compiler. Or one may want to know
>such things about the currently running kernel. Even user-space
>programs (like mount) may want to know (what NFS version? do we
>have CONFIG_JOLIET?).
>
>Today we supply a little of this information.
>For example, /proc/version supplies information on version
>and compiler and date. Why? One might as well keep this compiler
>info in a separate file. What a waste of unswappable kernel memory!
>
>You see - this is not a matter of absolutes.
>In the good old days, when an operating system had to fit in 4k
>and a device driver in 128 words, putting a 100-char text like
>the one found in /proc/version into the system would be ridiculous.
>Today nobody worries about a hundred bytes paid for some useful info.
>
>So, the question is: how useful is the information, and how expensive
>is it to store it. Consider the config options. How much space do they
>take? Typically 1-5 kB (compressed). If this is stored at the end of
>a kernel image file, and not loaded into memory, then the kernel memory
>cost is zero. If this is made part of the kernel itself, say accessible
>via /proc, then the cost is 1-5 kB.
>
>So, you should ponder whether it is worthwhile to pay this cost of zero,
>and ponder whether it is worthwhile to pay this cost of 5 kB.
>

I think it's insanely useful at times.  Especially if you're doing 
something like building an embedded box where you're building some of 
your own drivers and making some kernel mods.  And you've got a team of 
5 or more people.  

I've written a simple hack that puts .config in the proc filesystem. 
 I'll send it if you want.  It bzip2 the .config file and then you can 
bzcat /proc/kernconfig to see what your kernel was made with.  It's not 
a good general purpose solution but it worked for what I was doing.

Ian

-- 
Ian S. Nelson <nelcomp@attglobal.net>        303-666-0315
Nelson Computing of Boulder Colorado
Networking/Contracting/Custom Software/Linux Fast and Personal service

Re: How to check the kernel compile options ?

[H. Peter Anvin]

Andries.Brouwer@cwi.nl wrote:

> 
> Peter, in my eyes this is an unreasonable answer.
> 
> For debugging and other purposes it is good to have some
> information. One may wish to know about a certain kernel image
> what Linux kernel version that was, with what patches, compiled
> with what options, by which compiler. Or one may want to know
> such things about the currently running kernel. Even user-space
> programs (like mount) may want to know (what NFS version? do we
> have CONFIG_JOLIET?).
> 


The proposed /proc/config stuff don't solve those problems, however.  For
one thing, either one of those might be in modules, and the modules might
not match what the kernel was compiled at the same time as.

	-hpa

Re: How to check the kernel compile options ?

[Alan Cox]

> So, you should ponder whether it is worthwhile to pay this cost of zero,
> and ponder whether it is worthwhile to pay this cost of 5 kB.

If you are going to cat it onto the end of the kernel image just mark 
it __initdata and shove a known symbol name on it. It'll get dumped out
of memory and you can find it trivially by using tools on the binary

Re: How to check the kernel compile options ?

[Christoph Rohland]

Hi Alan,

On Wed, 6 Feb 2002, Alan Cox wrote:
>> So, you should ponder whether it is worthwhile to pay this cost of
>> zero, and ponder whether it is worthwhile to pay this cost of 5 kB.
> 
> If you are going to cat it onto the end of the kernel image just
> mark it __initdata and shove a known symbol name on it. It'll get
> dumped out of memory and you can find it trivially by using tools on
> the binary

What about putting such info into a (swappable) tmpfs file with
shmem_file_setup?

Greetings
		Christoph

Re: How to check the kernel compile options ?

[Alan Cox]

> > If you are going to cat it onto the end of the kernel image just
> > mark it __initdata and shove a known symbol name on it. It'll get
> > dumped out of memory and you can find it trivially by using tools on
> > the binary
> 
> What about putting such info into a (swappable) tmpfs file with
> shmem_file_setup?

That is indeed an extremely cunning plan. Paticularly as /proc/config can
be a symlink to it

Re: How to check the kernel compile options ?

[Christoph Rohland]

Hi Alan,

On Wed, 6 Feb 2002, Alan Cox wrote:
> That is indeed an extremely cunning plan. Paticularly as
> /proc/config can be a symlink to it

Not a symlink, but the implementation. We could make a generic
interface something like proc_make_info_file(name, buffer, length).

Greetings
		Christoph

Re: How to check the kernel compile options ?

[Alex Bligh - linux-kernel]

--On Wednesday, 06 February, 2002 4:31 PM +0100 Christoph Rohland 
<cr@sap.com> wrote:

> Not a symlink, but the implementation. We could make a generic
> interface something like proc_make_info_file(name, buffer, length).

& perhaps even on kernel load go through each appropriately
tagged elf section and just add it. That way the make process
could add (possibly distribution specific) files to the kernel
image /OR NOT ADD ANY/ without changes to the 'real' code.

--
Alex Bligh

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Wed, 6 Feb 2002, Alan Cox wrote:

| > > If you are going to cat it onto the end of the kernel image just
| > > mark it __initdata and shove a known symbol name on it. It'll get
| > > dumped out of memory and you can find it trivially by using tools on
| > > the binary
| >
| > What about putting such info into a (swappable) tmpfs file with
| > shmem_file_setup?
|
| That is indeed an extremely cunning plan. Paticularly as /proc/config can
| be a symlink to it
| -

I still prefer your suggestion to append it to the kernel image
as __initdata so that it's discarded from memory but can be
read with some tool(s).

-- 
~Randy

Re: How to check the kernel compile options ?

[Padraig Brady]

Randy.Dunlap wrote:
> On Wed, 6 Feb 2002, Alan Cox wrote:
> 
> | > > If you are going to cat it onto the end of the kernel image just
> | > > mark it __initdata and shove a known symbol name on it. It'll get
> | > > dumped out of memory and you can find it trivially by using tools on
> | > > the binary
> | >
> | > What about putting such info into a (swappable) tmpfs file with
> | > shmem_file_setup?
> |
> | That is indeed an extremely cunning plan. Paticularly as /proc/config can
> | be a symlink to it
> | -
> 
> I still prefer your suggestion to append it to the kernel image
> as __initdata so that it's discarded from memory but can be
> read with some tool(s).
> 
> 

I aggree. You shouldn't need the kernel running to be able
to read it's config settings from it. You could do the
equivalent of the following at the end of the build.

<.config sed -e '/^#/d' -e '/^[    ]*$/d' | gzip -9 >> image

The sed scripts strip comments and blank lines.

Padraig.

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Wed, 6 Feb 2002, Randy.Dunlap wrote:

> I still prefer your suggestion to append it to the kernel image
> as __initdata so that it's discarded from memory but can be
> read with some tool(s).

The problem is that it make the kernel image larger, which lives in /boot
on many systems. Putting it in a module directory, even if not a module,
would be a better place for creative boot methods, of which there are
many.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 9, 2002 07:15 pm, Bill Davidsen wrote:
> On Wed, 6 Feb 2002, Randy.Dunlap wrote:
> 
> > I still prefer your suggestion to append it to the kernel image
> > as __initdata so that it's discarded from memory but can be
> > read with some tool(s).
> 
> The problem is that it make the kernel image larger, which lives in /boot
> on many systems. Putting it in a module directory, even if not a module,
> would be a better place for creative boot methods, of which there are
> many.

You don't seem to be clear on the concept of 'option'.

-- 
Daniel

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Mon, 11 Feb 2002, Daniel Phillips wrote:

> On February 9, 2002 07:15 pm, Bill Davidsen wrote:
> > On Wed, 6 Feb 2002, Randy.Dunlap wrote:
> > 
> > > I still prefer your suggestion to append it to the kernel image
> > > as __initdata so that it's discarded from memory but can be
> > > read with some tool(s).
> > 
> > The problem is that it make the kernel image larger, which lives in /boot
> > on many systems. Putting it in a module directory, even if not a module,
> > would be a better place for creative boot methods, of which there are
> > many.
> 
> You don't seem to be clear on the concept of 'option'.

Did I miss discussion of an option to put it somewhere other than as part
of the kernel? Sorry, I missed that.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Alex Bligh - linux-kernel]

>> > The problem is that it make the kernel image larger, which lives in
>> > /boot on many systems. Putting it in a module directory, even if not a
>> > module, would be a better place for creative boot methods, of which
>> > there are many.
>>
>> You don't seem to be clear on the concept of 'option'.
>
> Did I miss discussion of an option to put it somewhere other than as part
> of the kernel? Sorry, I missed that.

This option would be selected by typing 'n' into your
favourite kernel configuration utility.

--
Alex Bligh

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 11, 2002 08:05 pm, Bill Davidsen wrote:
> On Mon, 11 Feb 2002, Daniel Phillips wrote:
> 
> > On February 9, 2002 07:15 pm, Bill Davidsen wrote:
> > > On Wed, 6 Feb 2002, Randy.Dunlap wrote:
> > > 
> > > > I still prefer your suggestion to append it to the kernel image
> > > > as __initdata so that it's discarded from memory but can be
> > > > read with some tool(s).
> > > 
> > > The problem is that it make the kernel image larger, which lives in 
> > > /boot on many systems. Putting it in a module directory, even if not a 
> > > module, would be a better place for creative boot methods, of which 
> > > there are many.
> > 
> > You don't seem to be clear on the concept of 'option'.
> 
> Did I miss discussion of an option to put it somewhere other than as part
> of the kernel? Sorry, I missed that.

It's a trick question?  The config option would let you specify that no 
kernel config information at all would be stored with or in the kernel.  No 
cost, no memory footprint.  And I would get to have the extra warm n fuzzy 
usability I tend to go on at such lengths about.  So we're both happy, right? 

I'd even remain happy if the option were set *off* by default.

-- 
Daniel

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Tue, 12 Feb 2002, Daniel Phillips wrote:

> On February 11, 2002 08:05 pm, Bill Davidsen wrote:

> > Did I miss discussion of an option to put it somewhere other than as part
> > of the kernel? Sorry, I missed that.
> 
> It's a trick question?  The config option would let you specify that no 
> kernel config information at all would be stored with or in the kernel.  No 
> cost, no memory footprint.  And I would get to have the extra warm n fuzzy 
> usability I tend to go on at such lengths about.  So we're both happy, right? 
> 
> I'd even remain happy if the option were set *off* by default.

No trick other than to read what I said in either of the previous posts...
the question was not how to avoid having the useful feature, but how to
put it somewhere to avoid increasing the kernel size. I suggested in the
modules directory, either as a text file or as a module.

Disabling the feature is not the same as making it work optimally.

I like making it a module because it's obvious that modules_install is
needed. I see zero added utility from having it part of the kernel or
nothing, it's useful even to people booting from ROM, small /boot
partitions, etc.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> On Tue, 12 Feb 2002, Daniel Phillips wrote:
> 
> > On February 11, 2002 08:05 pm, Bill Davidsen wrote:
> 
> > > Did I miss discussion of an option to put it somewhere other than as part
> > > of the kernel? Sorry, I missed that.
> > 
> > It's a trick question?  The config option would let you specify that no 
> > kernel config information at all would be stored with or in the kernel.  No 
> > cost, no memory footprint.  And I would get to have the extra warm n fuzzy 
> > usability I tend to go on at such lengths about.  So we're both happy, right? 
> > 
> > I'd even remain happy if the option were set *off* by default.
> 
> No trick other than to read what I said in either of the previous posts...
> the question was not how to avoid having the useful feature, but how to
> put it somewhere to avoid increasing the kernel size. I suggested in the
> modules directory, either as a text file or as a module.

We are in violent agreement, I'm not sure where the misunderstanding came from.
Yes, the leading idea is to put it in a module.  In fact a patch exists, though
it may have issues, it's been a while since I looked at it.

Besides that, it's been suggested to stick it only the end of bzImage in a way
that some utility can find it, so that it never gets loaded into memory or does
and is immediately discarded.  Bootfs might be another way to go, or maybe
that's just a way of making the module solution more elegant.  Personally, I
think that making it a module is obviously the right way to go.  The exact
details of how the module would work haven't been hashed out yet, at least,
not recently.  I presume the module should be compressed.  Perhaps it should
only work in conjunction with some user space utility, allowing the config
info to be expressed even more compactly than otherwise possible.  There is a
lot of room for creative compression here - I roughed out a design at one point
that would be able to represent the config information in something like a
couple hundred bytes, when the compile is from a standard tree.  This is cute,
but it's probably more cute than necessary.

> Disabling the feature is not the same as making it work optimally.
> I like making it a module because it's obvious that modules_install is
> needed. I see zero added utility from having it part of the kernel or
> nothing, it's useful even to people booting from ROM, small /boot
> partitions, etc.

OK, my apologies for misinterpreting your position.

-- 
Daniel

Re: How to check the kernel compile options ?

[Padraig Brady]

Daniel Phillips wrote:
> On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> 
>>On Tue, 12 Feb 2002, Daniel Phillips wrote:
>>
>>
>>>On February 11, 2002 08:05 pm, Bill Davidsen wrote:
>>>
>>>>Did I miss discussion of an option to put it somewhere other than as part
>>>>of the kernel? Sorry, I missed that.
>>>>
>>>It's a trick question?  The config option would let you specify that no 
>>>kernel config information at all would be stored with or in the kernel.  No 
>>>cost, no memory footprint.  And I would get to have the extra warm n fuzzy 
>>>usability I tend to go on at such lengths about.  So we're both happy, right? 
>>>
>>>I'd even remain happy if the option were set *off* by default.
>>>
>>No trick other than to read what I said in either of the previous posts...
>>the question was not how to avoid having the useful feature, but how to
>>put it somewhere to avoid increasing the kernel size. I suggested in the
>>modules directory, either as a text file or as a module.
>>
> 
> We are in violent agreement, I'm not sure where the misunderstanding came from.
> Yes, the leading idea is to put it in a module.  In fact a patch exists, though
> it may have issues, it's been a while since I looked at it.
> 
> Besides that, it's been suggested to stick it only the end of bzImage in a way
> that some utility can find it, so that it never gets loaded into memory or does
> and is immediately discarded.

I'd go for tacking it on at the end of the bzImage. Advantages would be
that it can be read even when the kernel isn't loaded, and also there
is no danger of loading a module in another kernel.

Padraig.

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Tue, 12 Feb 2002, Padraig Brady wrote:

> I'd go for tacking it on at the end of the bzImage. Advantages would be
> that it can be read even when the kernel isn't loaded, and also there
> is no danger of loading a module in another kernel.

There are several problems with that:
1 - built into the kernel it is compressed and needs a tool to read
2 - the reason kernels are compressed is to make them fit in small boot
    media, so adding something to the image is not to be done lightly.
3 - modules are NOT compressed, and can be read with the strings command.
4 - other files in the modules directory are pure text and if the config
    was just text it could be read with `cat.'

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 12, 2002  13:32 -0500, Bill Davidsen wrote:
> On Tue, 12 Feb 2002, Padraig Brady wrote:
> > I'd go for tacking it on at the end of the bzImage. Advantages would be
> > that it can be read even when the kernel isn't loaded, and also there
> > is no danger of loading a module in another kernel.
> 
> There are several problems with that:
> 1 - built into the kernel it is compressed and needs a tool to read
> 2 - the reason kernels are compressed is to make them fit in small boot
>     media, so adding something to the image is not to be done lightly.
> 3 - modules are NOT compressed, and can be read with the strings command.
> 4 - other files in the modules directory are pure text and if the config
>     was just text it could be read with `cat.'

My thought on this is to make it a tristate [y/m/n] and have it print
output via /dev/kconfig or similar.  There could be a dep_bool which
keeps it in-core, or puts it in an init function which is discarded
after boot.  If you don't want to have it at all, you turn it off.
If you want it in the kernel, but not in memory all the time, it can
be in an init function (maybe printk'ing it before startup is done?).
It can be in a module and you can get the original plain-text config
back with "cat /dev/kconfig" and if it is a module it will be auto-loaded
from wherever it is.

You can also extract it from an uncompressed kernel (vmlinux) or the
module with "strings <file> | grep '[A-Z]*=[ym]$'".  It is simple
enough to search for the gzip magic (1f 8b 08 00 at about 16-18kB)
in a zImage or bzImage, and then pipe it to gunzip and strings as above.

The reason you need all of these config options (which don't end up
making the code much more complex) is because, for example, if you
are netbooting your kernel, you do not have access to any external
data or even the original kernel image on that system.  If it is in-memory
you use 15kB of RAM (5kB in the compressed image) for a fully-configured
vendor kernel, but you have the config options for THIS kernel and not
any "maybe it is right, maybe not" external file.

If it is a module, you can "cat /dev/kconfig > .config" to get a valid
config file, as long as you are sure this is the right module (maybe
modversions would help a bit, maybe not, or you could explicitly have
the kernel version string compiled into the module and compare it).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: How to check the kernel compile options ?

[Ville Herva]

On Tue, Feb 12, 2002 at 02:06:24PM -0700, you [Andreas Dilger] wrote:
> 
> You can also extract it from an uncompressed kernel (vmlinux) or the
> module with "strings <file> | grep '[A-Z]*=[ym]$'".  It is simple
> enough to search for the gzip magic (1f 8b 08 00 at about 16-18kB)
> in a zImage or bzImage, and then pipe it to gunzip and strings as above.

Such script could live in /usr/src/linux/scripts. The same script could
perhaps extract the version string as well. Anybody got a clue how to find
it reliably? Is this reliable 

strings /boot/bzImage |
 egrep '^[0-9]+\.[0-9]\.+.*\(.*@.*\).*[0-9]+:[0-9]+:[0-9]+' | 
 head -1


-- v --

v@iki.fi

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 13, 2002  00:10 +0200, Ville Herva wrote:
> On Tue, Feb 12, 2002 at 02:06:24PM -0700, you [Andreas Dilger] wrote:
> > 
> > You can also extract it from an uncompressed kernel (vmlinux) or the
> > module with "strings <file> | grep '[A-Z]*=[ym]$'".  It is simple
> > enough to search for the gzip magic (1f 8b 08 00 at about 16-18kB)
> > in a zImage or bzImage, and then pipe it to gunzip and strings as above.

Just as a clarification, the module configs can be stored in the short form:

EXPERIMENTAL=y
MODULES=y
PCI=y
:
:

I checked, in my current kernel/modules nothing matches the above regexp,
and even if it did, having a garbage config value wouldn't be fatal.

> Such script could live in /usr/src/linux/scripts. The same script could
> perhaps extract the version string as well. Anybody got a clue how to find
> it reliably? Is this reliable 
> 
> strings /boot/bzImage |
>  egrep '^[0-9]+\.[0-9]\.+.*\(.*@.*\).*[0-9]+:[0-9]+:[0-9]+' | 
>  head -1

This will work for the bzImage, but not the uncompressed kernel.  If you
remove the "^" (start of line) requirement it works for both:

egrep '[0-9]+\.[0-9]\.+.*\(.*@.*\).*[0-9]+:[0-9]+:[0-9]+'

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Tue, 12 Feb 2002, Andreas Dilger wrote:

| On Feb 12, 2002  13:32 -0500, Bill Davidsen wrote:
| > On Tue, 12 Feb 2002, Padraig Brady wrote:
| > > I'd go for tacking it on at the end of the bzImage. Advantages would be
| > > that it can be read even when the kernel isn't loaded, and also there
| > > is no danger of loading a module in another kernel.
| >
| > There are several problems with that:
| > 1 - built into the kernel it is compressed and needs a tool to read
| > 2 - the reason kernels are compressed is to make them fit in small boot
| >     media, so adding something to the image is not to be done lightly.
| > 3 - modules are NOT compressed, and can be read with the strings command.
| > 4 - other files in the modules directory are pure text and if the config
| >     was just text it could be read with `cat.'
|
| My thought on this is to make it a tristate [y/m/n] and have it print
| output via /dev/kconfig or similar.  There could be a dep_bool which
| keeps it in-core, or puts it in an init function which is discarded
| after boot.  If you don't want to have it at all, you turn it off.
| If you want it in the kernel, but not in memory all the time, it can
| be in an init function (maybe printk'ing it before startup is done?).
| It can be in a module and you can get the original plain-text config
| back with "cat /dev/kconfig" and if it is a module it will be auto-loaded
| from wherever it is.
|
| You can also extract it from an uncompressed kernel (vmlinux) or the
| module with "strings <file> | grep '[A-Z]*=[ym]$'".  It is simple
| enough to search for the gzip magic (1f 8b 08 00 at about 16-18kB)
| in a zImage or bzImage, and then pipe it to gunzip and strings as above.

Thanks for the info.

Yes, I can see the gzip header, using 'od'.

What's an existing tool to strip (delete) bootsect and setup
from the beginning of [b]zImage, up to the gzip header, so
that the rest of the file can be piped to gunzip ?
Otherwise I can write one.

Thanks,
-- 
~Randy

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 12, 2002  16:49 -0800, Randy.Dunlap wrote:
> On Tue, 12 Feb 2002, Andreas Dilger wrote:
> | My thought on this is to make it a tristate [y/m/n] and have it print
> | output via /dev/kconfig or similar.  There could be a dep_bool which
> | keeps it in-core, or puts it in an init function which is discarded
> | after boot.  If you don't want to have it at all, you turn it off.
> | If you want it in the kernel, but not in memory all the time, it can
> | be in an init function (maybe printk'ing it before startup is done?).
> | It can be in a module and you can get the original plain-text config
> | back with "cat /dev/kconfig" and if it is a module it will be auto-loaded
> | from wherever it is.
> |
> | You can also extract it from an uncompressed kernel (vmlinux) or the
> | module with "strings <file> | grep '[A-Z]*=[ym]$'".  It is simple
> | enough to search for the gzip magic (1f 8b 08 00 at about 16-18kB)
> | in a zImage or bzImage, and then pipe it to gunzip and strings as above.
> 
> Thanks for the info.
> 
> Yes, I can see the gzip header, using 'od'.
> 
> What's an existing tool to strip (delete) bootsect and setup
> from the beginning of [b]zImage, up to the gzip header, so
> that the rest of the file can be piped to gunzip ?
> Otherwise I can write one.

I thought that zcat might be a bit tolerant as to checking for gzip
magic not exactly at the beginning of the file.  There is something
like this as part of the "mknbi" tool (from etherboot) on SourceForge,
but it is probably just as easy to make a simple C program which looks
for the magic, and then execs zcat and pipes the rest of the file to it.

This would be useful for other things besides the config issue (e.g.
getting a vmlinux that you can run GDB with from a bzImage).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [lkml] Re: How to check the kernel compile options ?

[Ian Soboroff]

"Randy.Dunlap" <rddunlap@osdl.org> writes:

> Yes, I can see the gzip header, using 'od'.
> 
> What's an existing tool to strip (delete) bootsect and setup
> from the beginning of [b]zImage, up to the gzip header, so
> that the rest of the file can be piped to gunzip ?
> Otherwise I can write one.

tail +c ?  dd bs=1 skip=... ?

ian

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Tue, 12 Feb 2002, Daniel Phillips wrote:

> We are in violent agreement, I'm not sure where the misunderstanding came from.
> Yes, the leading idea is to put it in a module.  In fact a patch exists, though
> it may have issues, it's been a while since I looked at it.

> OK, my apologies for misinterpreting your position.

Not a problem, and I'm sorry the tone of my previous post was a bit
abrupt. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Horst von Brand]

Daniel Phillips <phillips@bonn-fries.net> said:
> On February 12, 2002 05:38 pm, Bill Davidsen wrote:

[...]

> > No trick other than to read what I said in either of the previous posts...
> > the question was not how to avoid having the useful feature, but how to
> > put it somewhere to avoid increasing the kernel size. I suggested in the
> > modules directory, either as a text file or as a module.

> We are in violent agreement, I'm not sure where the misunderstanding came
> from.  Yes, the leading idea is to put it in a module.  In fact a patch
> exists, though it may have issues, it's been a while since I looked at
> it.

A module can get displaced as easily as a plain text file, and the wrong
"configutarion module" version won't do any good in any case.

Just teach /sbin/installkernel (or arch/i386/install.sh) to stash it away
somewhere. You'll need to fix arch/i386/Makefile to pass the name of
.config to the script (note that it now takes 3 or 4 arguments, to get
backwards compatibility when taking 3, 4 or 5 will be tricky, unless you
play games with the name of the files passed into it to figure out where
.config lives). Or call a new script  if it is there and only give that one
.config plus the standard stuff.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 13, 2002 03:19 pm, Horst von Brand wrote:
> Daniel Phillips <phillips@bonn-fries.net> said:
> > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> 
> [...]
> 
> > > No trick other than to read what I said in either of the previous posts...
> > > the question was not how to avoid having the useful feature, but how to
> > > put it somewhere to avoid increasing the kernel size. I suggested in the
> > > modules directory, either as a text file or as a module.
> 
> > We are in violent agreement, I'm not sure where the misunderstanding came
> > from.  Yes, the leading idea is to put it in a module.  In fact a patch
> > exists, though it may have issues, it's been a while since I looked at
> > it.
> 
> A module can get displaced as easily as a plain text file, and the wrong
> "configutarion module" version won't do any good in any case.

Not necessarily, check out the work on bootfs, I think this can be adapted to
suit the purpose.  If the config is in a module then we'd normally want that
module to be one of the modules that is included in the boot image.

> Just teach /sbin/installkernel (or arch/i386/install.sh) to stash it away
> somewhere.

If that were satisfactory then there would be nobody posting to this thread.

> You'll need to fix arch/i386/Makefile to pass the name of
> .config to the script (note that it now takes 3 or 4 arguments, to get
> backwards compatibility when taking 3, 4 or 5 will be tricky, unless you
> play games with the name of the files passed into it to figure out where
> .config lives). Or call a new script  if it is there and only give that one
> .config plus the standard stuff.

There is no good way to know where you have put those things.  We're looking
for a tight coupling between the kernel image and metadata that describes
what's in it - like a label on an electronic component: stuck right on it,
not filed away in a filing cabinet.

-- 
Daniel

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Wed, 13 Feb 2002, Daniel Phillips wrote:

> > A module can get displaced as easily as a plain text file, and the wrong
> > "configutarion module" version won't do any good in any case.
> 
> Not necessarily, check out the work on bootfs, I think this can be adapted to
> suit the purpose.  If the config is in a module then we'd normally want that
> module to be one of the modules that is included in the boot image.

It should not be in the boot image, or at least it should be usable
elsewhere, because it isn't used at boot. It is only used in a running
system (not necessarily booted from the kernel in question, but running as
opposed to needed by lilo/grub).

> There is no good way to know where you have put those things.  We're looking
> for a tight coupling between the kernel image and metadata that describes
> what's in it - like a label on an electronic component: stuck right on it,
> not filed away in a filing cabinet.

But that tight coupling has a cost, and the reason for compressed kernel
is to make it small to fit {places}, which is one of the benefits of
modules. Putting it in the kernel or nowhere is not optimal, most people
can manage to find documentation which isn't bound that tightly. If it's
available as a module it's useful in all the ways people currently use
things they may or may not want in the kernel, even if "in the kernel"
only means "stuck to the boot image."

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1240 bytes --]

On Wed, 13 Feb 2002, Horst von Brand wrote:

> Daniel Phillips <phillips@bonn-fries.net> said:
> > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> 
> [...]
[SNIPPED...]

My idea is to take the .config file and remove most of its
redundancy and unnecessary verbage. Then, the result is
compressed and written to a constant global array, linked
into the kernel. Both the array and the array length will then
be available from /proc/kcore for user-mode tools to recreate the
.config file.

Here are tools and a test/documentation script that shows it
will work. The .config on my machine generates a 1730 byte
array. This is certainly small enough to not be considered
bloat.

The advantage, of course is that if you are executing the kernel,
it can give you all the information necessary to recreate a
new one from the sources because its .config is embeded into
itself. Once you have the ".config" file, you just do `make oldconfig`
and you are home free.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2738 bytes --]

Re: How to check the kernel compile options ?

[Randy.Dunlap]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1655 bytes --]

On Wed, 13 Feb 2002, Richard B. Johnson wrote:

| On Wed, 13 Feb 2002, Horst von Brand wrote:
|
| > Daniel Phillips <phillips@bonn-fries.net> said:
| > > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
| >
| > [...]
| [SNIPPED...]
|
| My idea is to take the .config file and remove most of its
| redundancy and unnecessary verbage. Then, the result is
| compressed and written to a constant global array, linked
| into the kernel. Both the array and the array length will then
| be available from /proc/kcore for user-mode tools to recreate the
| .config file.

This is a bit similar to what I did last weekend (and attach
here).  Mine goes into the kernel boot file, however, so that
it can be read even when the kernel isn't running.

I'll experiment with ideas from Andreas (thanks) or Ian Soboroff
to create a userspace get-config tool.

One small nit:  you say "user-mode tools", but /proc/kcore
is read-only for root only -- right?
That's not desirable or required IMO.

| Here are tools and a test/documentation script that shows it
| will work. The .config on my machine generates a 1730 byte
| array. This is certainly small enough to not be considered
| bloat.

Not a problem to me, although most people seem to want to see
it as a config option.
I plan to add that to what I've done...
and probably strip the leading "CONFIG_" strings.

| The advantage, of course is that if you are executing the kernel,
| it can give you all the information necessary to recreate a
| new one from the sources because its .config is embeded into
| itself. Once you have the ".config" file, you just do `make oldconfig`
| and you are home free.

-- 
~Randy

[-- Attachment #2: Type: TEXT/PLAIN, Size: 5741 bytes --]

--- linux-2416/Makefile.org	Mon Nov 26 05:29:17 2001
+++ linux-2416/Makefile	Wed Feb 13 09:16:39 2002
@@ -257,8 +257,8 @@
 boot: vmlinux
 	@$(MAKE) CFLAGS="$(CFLAGS) $(CFLAGS_KERNEL)" -C arch/$(ARCH)/boot
 
-vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
-	$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
+vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o init/version.o init/configs.o linuxsubdirs
+	$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o init/configs.o \
 		--start-group \
 		$(CORE_FILES) \
 		$(DRIVERS) \
@@ -334,6 +334,13 @@
 
 init/main.o: init/main.c include/config/MARKER
 	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) $(PROFILING) -c -o $*.o $<
+
+scripts/mkconfigs: scripts/mkconfigs.c
+	$(HOSTCC) $(HOSTCFLAGS) -o scripts/mkconfigs scripts/mkconfigs.c
+
+init/configs.o: scripts/mkconfigs $(TOPDIR)/.config include/config/MARKER
+	scripts/mkconfigs $(TOPDIR)/.config init/configs.c
+	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DEXPORT_SYMTAB -c -o init/configs.o init/configs.c
 
 fs lib mm ipc kernel drivers net: dummy
 	$(MAKE) CFLAGS="$(CFLAGS) $(CFLAGS_KERNEL)" $(subst $@, _dir_$@, $@)
--- /home/rddunlap/doc/epoch	Wed May 24 09:51:00 2000
+++ linux-2416/scripts/mkconfigs.c	Wed Feb 13 09:07:20 2002
@@ -0,0 +1,155 @@
+/***************************************************************************
+ * mkconfigs.c
+ * (C) 2002 Randy Dunlap <rddunlap@osdl.org>
+
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software
+#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+# Rules for scripts/mkconfigs.c input.config output.c
+# to generate configs.c from linux/.config:
+# - drop lines that begin with '#'
+# - drop blank lines
+# - lines that use double-quotes must \\-escape-quote them
+
+################## skeleton configs.c file: ####################
+
+#include <linux/init.h>
+#include <linux/module.h>
+
+static char *configs[] __initdata =
+
+  <insert lines selected lines of .config, quoted, with added '\n'>,
+
+;
+
+################### end configs.c file ######################
+
+****************************************************************/
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <errno.h>
+
+#define VERSION		"0.1"
+#define LINE_SIZE	1000
+
+void usage (const char *progname)
+{
+	fprintf (stderr, "%s ver. %s\n", progname, VERSION);
+	fprintf (stderr, "usage:  %s input.config.name path/configs.c\n",
+			progname);
+	exit (1);
+}
+
+void make_intro (FILE *sourcefile)
+{
+	fprintf (sourcefile, "#include <linux/init.h>\n");
+	fprintf (sourcefile, "#include <linux/module.h>\n");
+	fprintf (sourcefile, "\n");
+	fprintf (sourcefile, "/*static*/ char /*__attribute__ ((unused))*/ *configs[] __initdata = {\n");
+	fprintf (sourcefile, "  \"CONFIG_BEGIN=n \" ,\n");
+}
+
+void make_ending (FILE *sourcefile)
+{
+	fprintf (sourcefile, "  \"CONFIG_END=n \"\n");
+	fprintf (sourcefile, "};\n");
+	fprintf (sourcefile, "EXPORT_SYMBOL (configs);\n");
+}
+
+void make_lines (FILE *configfile, FILE *sourcefile)
+{
+	char cfgline[LINE_SIZE];
+	char *ch;
+
+	while (fgets (cfgline, LINE_SIZE, configfile)) {
+		if (cfgline[0] == '#' ||
+		    cfgline[0] == '\n')
+			continue;
+		/* kill the trailing newline in cfgline */
+		cfgline[strlen (cfgline) - 1] = '\0';
+
+		/*
+		 * use strchr() to check for "-quote in cfgline;
+		 * if not found, output the line, quoted;
+		 * if found, output a char at a time, with \\-quote
+		 * preceding double-quote chars
+		 */
+		if (!strchr (cfgline, '"')) {
+			fprintf (sourcefile, "  \"%s \" ,\n", cfgline);
+			continue;
+		}
+
+		/* go to char-at-a-time mode for this cfgline and
+		 * precede any double-quote with a backslash */
+		fprintf (sourcefile, "  \"");	/* lead-in */
+		for (ch = cfgline; *ch; ch++) {
+			if (*ch == '"')
+				fputc ('\\', sourcefile);
+			fputc (*ch, sourcefile);
+		}
+		fprintf (sourcefile, " \" ,\n");
+	}
+}
+
+int make_configs (FILE *configfile, FILE *sourcefile)
+{
+	make_intro (sourcefile);
+	make_lines (configfile, sourcefile);
+	make_ending (sourcefile);
+}
+
+int main (int argc, char *argv[])
+{
+	char *progname = argv[0];
+	char *configname, *sourcename;
+	FILE *configfile, *sourcefile;
+
+	if (argc != 3)
+		usage (progname);
+
+	configname = argv[1];
+	sourcename = argv[2];
+
+	configfile = fopen (configname, "r");
+	if (!configfile) {
+		fprintf (stderr, "%s: cannot open '%s'\n",
+				progname, configname);
+		exit (2);
+	}
+	sourcefile = fopen (sourcename, "w");
+	if (!sourcefile) {
+		fprintf (stderr, "%s: cannot open '%s'\n",
+				progname, sourcename);
+		exit (2);
+	}
+
+	make_configs (configfile, sourcefile);
+
+	if (fclose (sourcefile)) {
+		fprintf (stderr, "%s: error %d closing '%s'\n",
+				progname, errno, sourcename);
+		exit (3);
+	}
+	if (fclose (configfile)) {
+		fprintf (stderr, "%s: error %d closing '%s'\n",
+				progname, errno, configname);
+		exit (3);
+	}
+
+	exit (0);
+}
+
+/* end mkconfigs.c */

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 13, 2002 07:09 pm, Randy.Dunlap wrote:
> On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> 
> | On Wed, 13 Feb 2002, Horst von Brand wrote:
> |
> | > Daniel Phillips <phillips@bonn-fries.net> said:
> | > > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> | >
> | > [...]
> | [SNIPPED...]
> |
> | My idea is to take the .config file and remove most of its
> | redundancy and unnecessary verbage. Then, the result is
> | compressed and written to a constant global array, linked
> | into the kernel. Both the array and the array length will then
> | be available from /proc/kcore for user-mode tools to recreate the
> | .config file.
> 
> This is a bit similar to what I did last weekend (and attach
> here).  Mine goes into the kernel boot file, however, so that
> it can be read even when the kernel isn't running.
> 
> I'll experiment with ideas from Andreas (thanks) or Ian Soboroff
> to create a userspace get-config tool.
> 
> One small nit:  you say "user-mode tools", but /proc/kcore
> is read-only for root only -- right?
> That's not desirable or required IMO.

Binary proc or a char device would be a much better idea, and of those
binary proc seems the most elegant, something like:

  cat /proc/binary/kernel/config | kernelconfig > .config

-- 
Daniel

Re: How to check the kernel compile options ?

[Richard B. Johnson]

On Wed, 13 Feb 2002, Randy.Dunlap wrote:

> On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> 
> | On Wed, 13 Feb 2002, Horst von Brand wrote:
> |
> | > Daniel Phillips <phillips@bonn-fries.net> said:
> | > > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> | >
> | > [...]
> | [SNIPPED...]
> |
> | My idea is to take the .config file and remove most of its
> | redundancy and unnecessary verbage. Then, the result is
> | compressed and written to a constant global array, linked
> | into the kernel. Both the array and the array length will then
> | be available from /proc/kcore for user-mode tools to recreate the
> | .config file.
> 
> This is a bit similar to what I did last weekend (and attach
> here).  Mine goes into the kernel boot file, however, so that
> it can be read even when the kernel isn't running.
> 
> I'll experiment with ideas from Andreas (thanks) or Ian Soboroff
> to create a userspace get-config tool.
> 
> One small nit:  you say "user-mode tools", but /proc/kcore
> is read-only for root only -- right?
> That's not desirable or required IMO.
> 

Hmmm. You are going to make a kernel and don't have root-access to
create a kernel configuration file?

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 13, 2002 07:27 pm, Richard B. Johnson wrote:
> On Wed, 13 Feb 2002, Randy.Dunlap wrote:
> 
> > On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> > 
> > | On Wed, 13 Feb 2002, Horst von Brand wrote:
> > |
> > | > Daniel Phillips <phillips@bonn-fries.net> said:
> > | > > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
> > | >
> > | > [...]
> > | [SNIPPED...]
> > |
> > | My idea is to take the .config file and remove most of its
> > | redundancy and unnecessary verbage. Then, the result is
> > | compressed and written to a constant global array, linked
> > | into the kernel. Both the array and the array length will then
> > | be available from /proc/kcore for user-mode tools to recreate the
> > | .config file.
> > 
> > This is a bit similar to what I did last weekend (and attach
> > here).  Mine goes into the kernel boot file, however, so that
> > it can be read even when the kernel isn't running.
> > 
> > I'll experiment with ideas from Andreas (thanks) or Ian Soboroff
> > to create a userspace get-config tool.
> > 
> > One small nit:  you say "user-mode tools", but /proc/kcore
> > is read-only for root only -- right?
> > That's not desirable or required IMO.
> 
> Hmmm. You are going to make a kernel and don't have root-access to
> create a kernel configuration file?

Reducing the number of operations that have to be performed as root
is Good[tm].

-- 
Daniel

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Wed, 13 Feb 2002, Randy.Dunlap wrote:

| On Wed, 13 Feb 2002, Richard B. Johnson wrote:
|
| | On Wed, 13 Feb 2002, Horst von Brand wrote:
| |
| | > Daniel Phillips <phillips@bonn-fries.net> said:
| | > > On February 12, 2002 05:38 pm, Bill Davidsen wrote:
| | >
| | > [...]
| | [SNIPPED...]
| |
| | My idea is to take the .config file and remove most of its
| | redundancy and unnecessary verbage. Then, the result is
| | compressed and written to a constant global array, linked
| | into the kernel. Both the array and the array length will then
| | be available from /proc/kcore for user-mode tools to recreate the
| | .config file.
|
| This is a bit similar to what I did last weekend (and attach
| here).  Mine goes into the kernel boot file, however, so that
| it can be read even when the kernel isn't running.
|
| I'll experiment with ideas from Andreas (thanks) or Ian Soboroff
| to create a userspace get-config tool.
|
| One small nit:  you say "user-mode tools", but /proc/kcore
| is read-only for root only -- right?
| That's not desirable or required IMO.


| On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> Hmmm. You are going to make a kernel and don't have root-access to
> create a kernel configuration file?

Well, I did say "small nit".  But some of us prefer to run
as root as little as possible, and building a kernel
certainly doesn't require root privileges.
Only installing it does (or may).

~Randy

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Wed, 13 Feb 2002, Richard B. Johnson wrote:

> The advantage, of course is that if you are executing the kernel,
> it can give you all the information necessary to recreate a
> new one from the sources because its .config is embeded into
> itself. Once you have the ".config" file, you just do `make oldconfig`
> and you are home free.

But it does no such thing! You not only need the config file, you need the
source. So you now need to add to the kernel the entire source tree from
which it was built, or perhaps just a diff file from a kernel.org source,
which you will suitably compress, of course.

And without all that information you can't be sure of being able to build
a working kernel, only of knowing what options you selected, but not what
they (exactly) meant. Don't forget to save the C compiler and any
libraries and system include files inn the kernel as well, can't be half
safe.

This feature just isn't all that useful, I use an install script which
does copy the config file, compresses it into a zip with a file comment of
the MD5 of the kernel image, and adds the Makefile as well. I build
kernels almost every week, I support a whole raft of machines, and after I
got this whole nice script running I have used about twice a year.

I don't want anything added to my boot kernel image which isn't absolutely
needed to get the machine up, not documentation, not digitized cartoons,
not comments, etc. This is not an issue if you boot from a fat multi-GB
hard drive, it is if you boot from ROM, Compact flash pretending to be a
tiny IDE disk, need to be able to recovery boot from floppy, etc.

The feature would be nice, but "I can't manage to keep my kernel and
modules together" is not reason to oppose putting config in a module, or a
text file, or anywhere better organized people WOULD be able to find it.
If you want an option to put all that stuff you don't need into the boot
image, go to it, just don't make it useless to other people.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Richard B. Johnson]

On Wed, 13 Feb 2002, Bill Davidsen wrote:

> On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> 
> > The advantage, of course is that if you are executing the kernel,
> > it can give you all the information necessary to recreate a
> > new one from the sources because its .config is embeded into
> > itself. Once you have the ".config" file, you just do `make oldconfig`
> > and you are home free.
> 
> But it does no such thing! You not only need the config file, you need the
> source. So you now need to add to the kernel the entire source tree from
> which it was built, or perhaps just a diff file from a kernel.org source,
> which you will suitably compress, of course.

What the F..? You are outa your mind. The PURPOSE is to create a .config
from which one can do a `make oldconfig` and get the same drivers,
modules, etc., that you have in the running kernel.

Of course you need a kernel source-code tree.

[SNIPPED rest of g...]

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Wed, 13 Feb 2002, Richard B. Johnson wrote:

> On Wed, 13 Feb 2002, Bill Davidsen wrote:
> 
> > On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> > 
> > > The advantage, of course is that if you are executing the kernel,
> > > it can give you all the information necessary to recreate a
> > > new one from the sources because its .config is embeded into
> > > itself. Once you have the ".config" file, you just do `make oldconfig`
> > > and you are home free.
> > 
> > But it does no such thing! You not only need the config file, you need the
> > source. So you now need to add to the kernel the entire source tree from
> > which it was built, or perhaps just a diff file from a kernel.org source,
> > which you will suitably compress, of course.
> 
> What the F..? You are outa your mind. The PURPOSE is to create a .config
> from which one can do a `make oldconfig` and get the same drivers,
> modules, etc., that you have in the running kernel.
> 
> Of course you need a kernel source-code tree.

If you are going to build the same kernel you don't need *a* kernel source
code tree, you need the same kernel source code tree. Anyone who has
turned off an option because it had a bug in one kernel release will
assure you that config files for one kernel are not always safe or
functional on another.

I didn't think anyone would take that literally, I was making the point
that the config is "necessary but not sufficient" to borrow an engineering
term, and that the config is not the whole solution.

Did you build your mail reader with the sarcasm and hyperbole detector
option off?

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Ben Greear]

Bill Davidsen wrote:


> Did you build your mail reader with the sarcasm and hyperbole detector
> option off?


And now how could he possibly know what options he built it
with...or maybe it has it's .config in it somewhere? ;)


> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 13, 2002  16:21 -0700, Ben Greear wrote:
> Bill Davidsen wrote:
> > Did you build your mail reader with the sarcasm and hyperbole detector
> > option off?
> 
> And now how could he possibly know what options he built it
> with...or maybe it has it's .config in it somewhere? ;)

   $ mutt -v
   Mutt 1.2.5i (2000-07-28)
   Copyright (C) 1996-2000 Michael R. Elkins and others.
   Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
   Mutt is free software, and you are welcome to redistribute it
   under certain conditions; type `mutt -vv' for details.

   System: Linux 2.4.17-pre8 [using slang 10402]
   Compile options:
   -DOMAIN
   -DEBUG
   -HOMESPOOL  -USE_SETGID  -USE_DOTLOCK  +USE_FCNTL  -USE_FLOCK
   +USE_IMAP  -USE_GSS  +USE_SSL  +USE_POP  +HAVE_REGCOMP  -USE_GNU_REGEX  
   +HAVE_COLOR  +HAVE_PGP  -BUFFY_SIZE -EXACT_ADDRESS  +ENABLE_NLS  +COMPRESSED
   SENDMAIL="/usr/sbin/sendmail"
   MAILPATH="/var/spool/mail"
   SHAREDIR="/usr/share/mutt"
   SYSCONFDIR="/etc"
   ISPELL="/usr/bin/ispell"
   To contact the developers, please mail to <mutt-dev@mutt.org>.
   To report a bug, please use the muttbug utility.

See, it's easy if the code supports it... ;-)

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: How to check the kernel compile options ?

[Ben Greear]

Bill Davidsen wrote:

> On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> 
> 
>>The advantage, of course is that if you are executing the kernel,
>>it can give you all the information necessary to recreate a
>>new one from the sources because its .config is embeded into
>>itself. Once you have the ".config" file, you just do `make oldconfig`
>>and you are home free.
>>
> 
> But it does no such thing! You not only need the config file, you need the
> source. So you now need to add to the kernel the entire source tree from
> which it was built, or perhaps just a diff file from a kernel.org source,
> which you will suitably compress, of course.


Heh, if you want to exactly copy your existing kernel, just use the
'cp' command!  Saving the config is more useful for those of us who
want to build a new kernel with new source that is *similar* to some
existing kernel.  Also, when an interesting bug (ie panic) occurs,
we can extract the .config automagically and send it along with
the ksymoops decode to the maintainers.  It's always easier to reproduce
the bug if you have the .config to the kernel that produced it.

Remember, you do not have to enable the feature.

Enjoy,
Ben



-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Wed, 13 Feb 2002, Ben Greear wrote:

> Bill Davidsen wrote:
> 
> > On Wed, 13 Feb 2002, Richard B. Johnson wrote:

> >>The advantage, of course is that if you are executing the kernel,
> >>it can give you all the information necessary to recreate a
> >>new one from the sources because its .config is embeded into
> >>itself. Once you have the ".config" file, you just do `make oldconfig`
> >>and you are home free.

> > But it does no such thing! You not only need the config file, you need the
> > source. So you now need to add to the kernel the entire source tree from
> > which it was built, or perhaps just a diff file from a kernel.org source,
> > which you will suitably compress, of course.
> 
> 
> Heh, if you want to exactly copy your existing kernel, just use the
> 'cp' command!  Saving the config is more useful for those of us who
> want to build a new kernel with new source that is *similar* to some
> existing kernel.  Also, when an interesting bug (ie panic) occurs,
> we can extract the .config automagically and send it along with
> the ksymoops decode to the maintainers.  It's always easier to reproduce
> the bug if you have the .config to the kernel that produced it.
> 
> Remember, you do not have to enable the feature.

No, but there's no reason to have it part of the kernel image as the only
solution. It works as a module, it works as a flat text data file in the
modules directory (except for those who can't match kernel to modules),
and ther's no reason why this can't exist somewhere which has no impact on
the size of the kernel image.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Randy.Dunlap]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1234 bytes --]

On Wed, 13 Feb 2002, Bill Davidsen wrote:

| On Wed, 13 Feb 2002, Ben Greear wrote:
|
[snippage]
|
| No, but there's no reason to have it part of the kernel image as the only
| solution. It works as a module, it works as a flat text data file in the
| modules directory (except for those who can't match kernel to modules),
| and ther's no reason why this can't exist somewhere which has no impact on
| the size of the kernel image.

I agree, if I understand you correctly.

I don't see a need for a CONFIG_SAVE_CONFIG option with value 'm'.
kbuild in 2.5 (or any script like 'installkernel') can do that by
copying the current .config file to the modules install directory
or the /boot directory.

I was hoping that (e)grep could search a (b)zImage file for
a binary pattern like the gzip header, but I couldn't make it
work.  I ended up writing a binary pattern search tool that
returns the offset of the located pattern, and then I feed
that value to tail | gunzip > strings | grep to get the
CONFIG text that was saved by the code that I posted yesterday.

I still plan to make this a config/build option (y/n) and
remove the leading "CONFIG_" parts of the strings.

binoffset.c and extract-config (script) attached.

-- 
~Randy


[-- Attachment #2: Type: TEXT/PLAIN, Size: 382 bytes --]

#! /bin/bash
# extracts .config info from a [b]zImage file
# uses binoffset (new), tail, gunzip, strings, and grep
# $arg1 is [b]zImage filename

gziphdr=`binoffset $1 0x1f 0x8b 0x08 0x0`
# increment by 1 since tail offsets are 1-based, not 0-based
gziphdr=$((gziphdr + 1))

tail -c +$gziphdr $1 | gunzip > $1.tmp
strings $1.tmp | grep CONFIG_ > $1.old.config
rm $1.tmp

[-- Attachment #3: Type: TEXT/PLAIN, Size: 4180 bytes --]

/***************************************************************************
 * binoffset.c
 * (C) 2002 Randy Dunlap <rddunlap@osdl.org>

#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

# binoffset.c:
# - searches a (binary) file for a specified (binary) pattern
# - returns the offset of the located pattern or ~0 if not found
# - exits with exit status 0 normally or non-0 if pattern is not found
#   or any other error occurs.

****************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#define VERSION		"0.1"
#define BUF_SIZE	(16 * 1024)
#define PAT_SIZE	100

char		*progname;
char		*inputname;
int		inputfd;
int		bix;			/* buf index */
unsigned char	patterns [PAT_SIZE] = {0}; /* byte-sized pattern array */
int		pat_len;		/* actual number of pattern bytes */
unsigned char	*madr;			/* mmap address */
size_t		filesize;
int		num_matches = 0;
off_t		firstloc = 0;

void usage (void)
{
	fprintf (stderr, "%s ver. %s\n", progname, VERSION);
	fprintf (stderr, "usage:  %s filename pattern_bytes\n",
			progname);
	fprintf (stderr, "        [prints location of pattern_bytes in file]\n");
	exit (1);
}

int get_pattern (int pat_count, char *pats [])
{
	int ix, err, tmp;

#ifdef DEBUG
	fprintf (stderr,"get_pattern: count = %d\n", pat_count);
	for (ix = 0; ix < pat_count; ix++)
		fprintf (stderr, "  pat # %d:  [%s]\n", ix, pats[ix]);
#endif

	for (ix = 0; ix < pat_count; ix++) {
		tmp = 0;
		err = sscanf (pats[ix], "%5i", &tmp);
		if (err != 1 || tmp > 0xff) {
			fprintf (stderr, "pattern or value error in pattern # %d [%s]\n",
					ix, pats[ix]);
			usage ();
		}
		patterns [ix] = tmp;
	}
	pat_len = pat_count;
}

int search_pattern (void)
{
	for (bix = 0; bix < filesize; bix++) {
		if (madr[bix] == patterns[0]) {
			if (memcmp (&madr[bix], patterns, pat_len) == 0) {
				if (num_matches == 0)
					firstloc = bix;
				num_matches++;
			}
		}
	}
}

#ifdef NOTDEF
size_t get_filesize (int fd)
{
	off_t end_off = lseek (fd, 0, SEEK_END);
	lseek (fd, 0, SEEK_SET);
	return (size_t) end_off;
}
#endif

size_t get_filesize (int fd)
{
	int err;
	struct stat stat;

	err = fstat (fd, &stat);
	fprintf (stderr, "filesize: %d\n", err < 0 ? err : stat.st_size);
	if (err < 0)
		return err;
	return (size_t) stat.st_size;
}

int main (int argc, char *argv [])
{
	progname = argv[0];

	if (argc < 3)
		usage ();

	get_pattern (argc - 2, argv + 2);

	inputname = argv[1];

	inputfd = open (inputname, O_RDONLY);
	if (inputfd == -1) {
		fprintf (stderr, "%s: cannot open '%s'\n",
				progname, inputname);
		exit (3);
	}

	filesize = get_filesize (inputfd);

	madr = mmap (0, filesize, PROT_READ, MAP_PRIVATE, inputfd, 0);
	if (madr == MAP_FAILED) {
		fprintf (stderr, "mmap error = %d\n", errno);
		close (inputfd);
		exit (4);
	}

	search_pattern ();

	if (munmap (madr, filesize))
		fprintf (stderr, "munmap error = %d\n", errno);

	if (close (inputfd))
		fprintf (stderr, "%s: error %d closing '%s'\n",
				progname, errno, inputname);

	fprintf (stderr, "number of pattern matches = %d\n", num_matches);
	if (num_matches == 0)
		firstloc = ~0;
	printf ("%d\n", firstloc);
	fprintf (stderr, "%d\n", firstloc);

	exit (num_matches ? 0 : 2);
}

/* end binoffset.c */

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 14, 2002  08:48 -0800, Randy.Dunlap wrote:
> gziphdr=`binoffset $1 0x1f 0x8b 0x08 0x0`
> # increment by 1 since tail offsets are 1-based, not 0-based
> gziphdr=$((gziphdr + 1))
> 
> tail -c +$gziphdr $1 | gunzip > $1.tmp
> strings $1.tmp | grep CONFIG_ > $1.old.config
> rm $1.tmp

How about something like the below (avoids writing a multi-MB temp file):

HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep CONFIG_

Note also that it is enough to store the config options without the
leading CONFIG_ part, and then use 'grep "[A-Z0-9]*=[ym]$"' to get
the actual config strings.  You can add a final 'sed "s/^/CONFIG_/"'
step to return it to the original format.  So:

dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep "[A-Z0-9]=[ym]$" \
	| sed "s/^//CONFIG_"

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Fri, 15 Feb 2002, Andreas Dilger wrote:

| On Feb 14, 2002  08:48 -0800, Randy.Dunlap wrote:
| > gziphdr=`binoffset $1 0x1f 0x8b 0x08 0x0`
| > # increment by 1 since tail offsets are 1-based, not 0-based
| > gziphdr=$((gziphdr + 1))
| >
| > tail -c +$gziphdr $1 | gunzip > $1.tmp
| > strings $1.tmp | grep CONFIG_ > $1.old.config
| > rm $1.tmp
|
| How about something like the below (avoids writing a multi-MB temp file):
|
| HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
| dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep CONFIG_

I tried that, but I didn't know about /dev/stdin,
so I agree with you.
I had tried 'strings -', but strings didn't like that.  :(

| Note also that it is enough to store the config options without the
| leading CONFIG_ part, and then use 'grep "[A-Z0-9]*=[ym]$"' to get
| the actual config strings.  You can add a final 'sed "s/^/CONFIG_/"'
| step to return it to the original format.  So:
|
| dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep "[A-Z0-9]=[ym]$" \
| 	| sed "s/^//CONFIG_"
| --

Yes, I said that I intended to remove the leading "CONFIG_".
I'll do that soon and package it all up and repost it.
Oh, and make it a CONFIG option.

Thanks for your help.

-- 
~Randy

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Fri, 15 Feb 2002, Randy.Dunlap wrote:

| On Fri, 15 Feb 2002, Andreas Dilger wrote:
|
| | On Feb 14, 2002  08:48 -0800, Randy.Dunlap wrote:
| | > gziphdr=`binoffset $1 0x1f 0x8b 0x08 0x0`
| | > # increment by 1 since tail offsets are 1-based, not 0-based
| | > gziphdr=$((gziphdr + 1))
| | >
| | > tail -c +$gziphdr $1 | gunzip > $1.tmp
| | > strings $1.tmp | grep CONFIG_ > $1.old.config
| | > rm $1.tmp
| |
| | How about something like the below (avoids writing a multi-MB temp file):
| |
| | HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
| | dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep CONFIG_
|
| I tried that, but I didn't know about /dev/stdin,
| so I agree with you.
| I had tried 'strings -', but strings didn't like that.  :(
|
| | Note also that it is enough to store the config options without the
| | leading CONFIG_ part, and then use 'grep "[A-Z0-9]*=[ym]$"' to get
| | the actual config strings.  You can add a final 'sed "s/^/CONFIG_/"'
| | step to return it to the original format.  So:
| |
| | dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep "[A-Z0-9]=[ym]$" \
| | 	| sed "s/^//CONFIG_"
| | --
|
| Yes, I said that I intended to remove the leading "CONFIG_".
| I'll do that soon and package it all up and repost it.
| Oh, and make it a CONFIG option.
|
| Thanks for your help.

Interim report:  I agree with the spirit of no temp. file, but one of
zcat or strings isn't working for me when I use only pipes.  The final
output file is empty (length = 0).

Hers's the current script:

HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
dd if=$1 bs=1 skip=$HDR | zcat - | strings /dev/stdin \
  | grep "[A-Za-z_0-9]=[ym]$" | sed "s/^/CONFIG_/" > $1.old.config

with the error output:

++ binoffset bzImage 0x1f 0x8b 0x08 0x0
filesize: 1086399
number of pattern matches = 1
19268
+ HDR=19268
+ dd if=bzImage bs=1 skip=19268
+ zcat -
+ strings /dev/stdin
32769+0 records in
32768+0 records out
/home/rddunlap/bin/extract-config: line 9: 13783 Broken pipe
dd if=$1 bs=1 skip=$HDR
     13784                       | zcat -
     13785 Segmentation fault      | strings /dev/stdin >$1.strings

This one works (no surprise):

HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
dd if=$1 bs=1 skip=$HDR | zcat - > $1.vmlin.tmp
strings $1.vmlin.tmp | grep "[A-Za-z_0-9]=[ym]$" \
  | sed "s/^/CONFIG_/" > $1.old.config
  rm $1.vmlin.tmp

any ideas or suggestions about this segfault problem?

thanks,
-- 
~Randy

Re: How to check the kernel compile options ?

[Andreas Dilger]

On Feb 15, 2002  17:10 -0800, Randy.Dunlap wrote:
> On Fri, 15 Feb 2002, Randy.Dunlap wrote:
> | On Fri, 15 Feb 2002, Andreas Dilger wrote:
> | | HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
> | | dd if=$1 bs=1 skip=$HDR | zcat | strings /dev/stdin | grep CONFIG_
> 
> Interim report:  I agree with the spirit of no temp. file, but one of
> zcat or strings isn't working for me when I use only pipes.  The final
> output file is empty (length = 0).
> 
> Hers's the current script:
> 
> HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
> dd if=$1 bs=1 skip=$HDR | zcat - | strings /dev/stdin \
>   | grep "[A-Za-z_0-9]=[ym]$" | sed "s/^/CONFIG_/" > $1.old.config

Hmm, I tried this, and it works with 'strings /dev/stdin < tmpfile' but
not 'cat tmpfile | strings /dev/stdin' which is sort of wierd.

I suppose you could always either:
a) fix 'strings' so that it accepts a '-' parameter to read from stdin
b) write a special-purpose 'strings | grep | sed' replacement tool for
   this purpose (or even include the binoffset part and link with zlib
   to do the decompression part).  No idea how hard it would be.  As
   for speed, almost anything would be faster in-memory than writing
   out the temp file.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: How to check the kernel compile options ?

[Andreas Ferber]

On Fri, Feb 15, 2002 at 03:51:43PM -0700, Andreas Dilger wrote:
> 
> Note also that it is enough to store the config options without the
> leading CONFIG_ part, and then use 'grep "[A-Z0-9]*=[ym]$"' to get
> the actual config strings.  You can add a final 'sed "s/^/CONFIG_/"'
> step to return it to the original format.  So:

Note that you also need some way to keep the config symbols which are
set to "n" and commented out in the .config. Otherwise you will have
to answer a lot of questions on "make oldconfig" ("yes n | make
oldconfig" isn't an option, as this doesn't tell you which config
symbols have been added).



I have actually done my own patch to include the .config into the
kernel image some time ago. It provides the .config via
/proc/config{,.gz,.bz2} (the compression method to use is
configurable). Apart from compression, it doesn't try to do anything
special to reduce size, because I don't have any machines where it
actually matters if the kernel needs some kB more or less memory.

I didn't bother to submit the patch because of the discussions on this
topic in the past, instead I keep patching kernel sources myself
before compiling a kernel. Anyone interested can get the patch from
<http://www.myipv6.de/patches/kconfig/>. Patches for new kernel
versions are uploaded occasionally, everytime I don't forget to rediff
it before applying other patches to the source tree ;-) (possibly
conflicting parts for other kernel versions are Makefiles, config.in
or Configure.help, which can all be hand-applied easily, even if you
are not a kernel hacker ;-). It works for both 2.2 and 2.4 (probably
2.5 also, didn't test yet).

Any comments on the patch are welcome ;-)

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Sat, 16 Feb 2002, Andreas Ferber wrote:

| On Fri, Feb 15, 2002 at 03:51:43PM -0700, Andreas Dilger wrote:
| >
| > Note also that it is enough to store the config options without the
| > leading CONFIG_ part, and then use 'grep "[A-Z0-9]*=[ym]$"' to get
| > the actual config strings.  You can add a final 'sed "s/^/CONFIG_/"'
| > step to return it to the original format.  So:

except that not all options are "=[ynm]$"; some are string values.

| Note that you also need some way to keep the config symbols which are
| set to "n" and commented out in the .config. Otherwise you will have
| to answer a lot of questions on "make oldconfig" ("yes n | make
| oldconfig" isn't an option, as this doesn't tell you which config
| symbols have been added).

Oh, thanks for pointing that out.

Will
  yes n | make oldconfig
build a kernel with the current y/m options still intact,
but any new or missing options set to 'n'?
That doesn't sound so bad, but not optimal either.

| I have actually done my own patch to include the .config into the
| kernel image some time ago. It provides the .config via
| /proc/config{,.gz,.bz2} (the compression method to use is
| configurable). Apart from compression, it doesn't try to do anything
| special to reduce size, because I don't have any machines where it
| actually matters if the kernel needs some kB more or less memory.
|
| I didn't bother to submit the patch because of the discussions on this
| topic in the past, instead I keep patching kernel sources myself
| before compiling a kernel. Anyone interested can get the patch from
| <http://www.myipv6.de/patches/kconfig/>. Patches for new kernel
| versions are uploaded occasionally, everytime I don't forget to rediff
| it before applying other patches to the source tree ;-) (possibly
| conflicting parts for other kernel versions are Makefiles, config.in
| or Configure.help, which can all be hand-applied easily, even if you
| are not a kernel hacker ;-). It works for both 2.2 and 2.4 (probably
| 2.5 also, didn't test yet).
|
| Any comments on the patch are welcome ;-)

I looked.  It does nicely if that's where you want to store and find
the .config.  I'd rather have it associated with a kernel image file
and accessible even if the kernel isn't running.

Thanks,
-- 
~Randy

Re: How to check the kernel compile options ?

[Andreas Ferber]

On Fri, Feb 22, 2002 at 11:56:31AM -0800, Randy.Dunlap wrote:
> 
> | Note that you also need some way to keep the config symbols which are
> | set to "n" and commented out in the .config. Otherwise you will have
> | to answer a lot of questions on "make oldconfig" ("yes n | make
> | oldconfig" isn't an option, as this doesn't tell you which config
> | symbols have been added).
> Will
>   yes n | make oldconfig
> build a kernel with the current y/m options still intact,
> but any new or missing options set to 'n'?

Yes. "make oldconfig" will only ask for options not contained in the old
 .config, and options it doesn't ask for don't take any input ;-)

> | I have actually done my own patch to include the .config into the
[...]
> I looked.  It does nicely if that's where you want to store and find
> the .config.  I'd rather have it associated with a kernel image file
> and accessible even if the kernel isn't running.

You can extract it. One possibility is to disable compression for
/proc/config and apply your "strings" magic.

The other way works if the config is GZIP compressed. Find the GZIP
magic in the vmlinuz, decompress the compressed part of the image (up
here it is like your "strings" variant), then search for GZIP magic
again and decompress.

Quick&dirty script for the latter (using your "binoffset" tool):

---------- snip ----------
#!/bin/sh
set -e
tmp=/tmp/$$
gziphdr=`binoffset $1 0x1f 0x8b 0x08 2>/dev/null`
dd if=$1 bs=1 skip=$gziphdr 2>/dev/null | gunzip > $tmp
gziphdr=`binoffset $tmp 0x1f 0x8b 0x08 2>/dev/null`
dd if=$tmp bs=1 skip=$gziphdr 2>/dev/null | gunzip
rm -f $tmp
---------- snip ----------

At the moment I'm just writing a tool which does all parts in one turn
(using zlib), to make it faster and more robust (the script above may
fail for example if the kernel image has more than one block of gzip
compressed data embedded). (It's actually working already, but the
code needs some heavy cleanup before it can be released to the public
;-) Come back in a few days for news...

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: How to check the kernel compile options ?

[Andreas Ferber]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

On Sat, Feb 23, 2002 at 08:02:24AM +0100, Andreas Ferber wrote:

> At the moment I'm just writing a tool which does all parts in one turn
> (using zlib), to make it faster and more robust (the script above may
> fail for example if the kernel image has more than one block of gzip
> compressed data embedded). (It's actually working already, but the
> code needs some heavy cleanup before it can be released to the public
> ;-) Come back in a few days for news...

Here we go again. Attached to this mail you find the announced kernel
config extractor. It is also available via HTTP: 

http://www.myipv6.de/patches/kconfig/dumpkconfig.c

It requires zlib to do the decompression stuff. As it is currently
lacking a Makefile, you have to compile it by hand (maybe you have to
add -I or -L parameters if you don't have zlib installed in the
standard search path):

gcc -o dumpkconfig dumpkconfig.c -lz

If you call it without arguments, it tries to read the kernel image
from stdin. Alternatively, you can give it a filename at the command
line.

It works on compressed kernel images as well as on uncompressed ones
(e.g. vmlinux or /proc/kcore). Obviously, CONFIG_PROC_CONFIG has to be
enabled for dumpkconfig to work, and you have to choose GZIP
compression for /proc/config. bzip2 compression is not yet supported
(and probably never will be, at least not by me), as is "none"
compression (Which has no magic to search for and no "end of data"
marker like gzip data, so it would be rather difficult to do. One
could add some to the kernel code, but I don't think it's worth it).

The code (and especially the error handling[1]) is still a bit wacky
and is missing documentation, but it is working fine here, so I
release it anyways.

If you experience any problems, please let me know.

Andreas

[1] Although this might turn out to be a feature in some cases, as
    gzip decompression errors are currently handled by ending the gzip
    stream and searching for the next gzip magic, which should make
    things more robust against spurious gzip magics in the kernel code.
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

[-- Attachment #2: dumpkconfig.c --]
[-- Type: text/plain, Size: 12398 bytes --]

/* dumpkconfig.c - read config data from kernel image
   Copyright (C) 2002 Andreas Ferber <af@myipv6.de>

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   Along with this program; if not, write to the Free Software Foundation,
   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

/*
 * This is a first attempt at extracting configuration data compiled in
 * via the kconfig patch (http://www.myipv6.de/patches/kconfig/) from a
 * kernel image without booting it. It only works if you enabled
 * CONFIG_PROC_CONFIG with gzip compression (CONFIG_PROC_CONFIG_GZ),
 * bzip2 or none compression are not yet supported (and probably will
 * never be).
 *
 * It will work on both a compressed (vmlinuz) or an uncompressed kernel
 * image (e.g. vmlinux or /proc/kcore), whatever you prefer.
 *
 * It needs zlib to extract the compressed data. Compile it with
 *
 *     gcc -o dumpkconfig dumpkconfig.c -lz
 *
 * Command line interface is very simple at the moment: without
 * arguments it tries to read stdin, otherwise it tries to open the file
 * named by the first command line parameter. The only other parameter
 * recognized at the moment is "--help"/"-h", which prints a usage
 * message and exits.
 */

#include <assert.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdarg.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <zlib.h>

/* size of stream buffers */
#define BUF_SIZE 8192

/* stream data */
struct streambuf {
    int type;
    char *buf, *buf_base;
    size_t buf_size;
    size_t buf_avail;
    size_t pos;
    int err:1,
        eof:1,
        eof_pending:1;
    union {
        struct {
            FILE *fd;
            char *fname;
        } f;
        struct {
            z_streamp zstrm;
            struct streambuf *input;
        } z;
    } src;
    size_t (*read) (struct streambuf *s, void *buf, size_t size);
    void (*close) (struct streambuf *s);
};

#define STREAM_FILE 1
#define STREAM_GZIP 2

/* gzip file header flags
 * unfortunately, zlib.h doesn't define these flags, so we have to
 * define it here */
#define ASCII_FLAG   0x01 /* bit 0 set: file probably ascii text */
#define HEAD_CRC     0x02 /* bit 1 set: header CRC present */
#define EXTRA_FIELD  0x04 /* bit 2 set: extra field present */
#define ORIG_NAME    0x08 /* bit 3 set: original file name present */
#define COMMENT      0x10 /* bit 4 set: file comment present */
#define RESERVED     0xE0 /* bits 5..7: reserved */

void error(const char *msg, ...)
{
    va_list args;
    va_start(args, msg);
    vfprintf(stderr, msg, args);
    va_end(args);
}

#define FATAL(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)

/*
 * Generic stream methods
 */

/* create a new empty stream object and allocate a buffer for it */
struct streambuf *alloc_stream(void)
{
    struct streambuf *s;

    s = calloc(1, sizeof(struct streambuf));
    if (s == NULL)
        FATAL("malloc");

    s->buf_base = malloc(BUF_SIZE);
    if (s->buf_base == NULL)
        FATAL("malloc");
    s->buf = s->buf_base;

    s->buf_size = BUF_SIZE;

    return s;
}

/* free a stream object and it's buffer */
void free_stream(struct streambuf *s)
{
    free(s->buf_base);
    free(s);
}

/* fill the stream buffer via the ->read() function */
int fill_buffer(struct streambuf *s)
{
    /* stop buffer fill if at least 80% are filled */
    size_t min_fill = (s->buf_size/10)*8;

    if (s->err)
        return 0;

    if (s->buf != s->buf_base) {
        if (s->buf_avail != 0)
            memmove(s->buf_base, s->buf, s->buf_avail);
        s->buf = s->buf_base;
    }

    while (!s->eof_pending && !s->eof && s->buf_avail < min_fill) {
        size_t r = s->read(s, s->buf+s->buf_avail, s->buf_size-s->buf_avail);
        if (s->err)
            return 0;
        s->buf_avail += r;
    }
    if (s->eof_pending && s->buf_avail == 0)
        s->eof = 1;
    return 1;
}

void consume(struct streambuf *s, size_t bytes)
{
    if (bytes < s->buf_avail) {
        s->buf += bytes;
        s->pos += bytes;
        s->buf_avail -= bytes;
    }
    else {
        s->pos += s->buf_avail;
        s->buf_avail = 0;
    }
    if (s->buf_avail == 0) {
        s->buf = s->buf_base;
        if (s->eof_pending)
            s->eof = 1;
    }
}

void close_stream(struct streambuf *s)
{
    s->close(s);
    free_stream(s);
}

size_t file_stream_read(struct streambuf *s, void *buf, size_t size)
{
    size_t r;
    
    assert(s->type == STREAM_FILE);

    r = fread(buf, 1, size, s->src.f.fd);
    if (ferror(s->src.f.fd))
        FATAL(s->src.f.fname);
    if (feof(s->src.f.fd))
        s->eof_pending = 1;
    return r;
}

void file_stream_close(struct streambuf *s)
{
    if (s->src.f.fd)
        fclose(s->src.f.fd);
    if (s->src.f.fname)
        free(s->src.f.fname);
}

struct streambuf *file_stream_new(const char *fname)
{
    struct streambuf *s;

    s = alloc_stream();

    s->type = STREAM_FILE;

    s->read = file_stream_read;
    s->close = file_stream_close;

    if (fname == NULL) {
        s->src.f.fd = stdin;
        return s;
    }

    if ((s->src.f.fname = strdup(fname)) == NULL)
        FATAL("strdup");

    if ((s->src.f.fd = fopen(fname, "r")) == NULL)
        FATAL(fname);

    return s;
}

voidpf zlib_alloc(voidpf opaque, uInt items, uInt size)
{
    return malloc(items*size);
}

void zlib_free(voidpf opaque, voidpf mem)
{
    free(mem);
}

size_t z_stream_read(struct streambuf *s, void *buf, size_t size)
{
    z_streamp z = s->src.z.zstrm;
    struct streambuf *src = s->src.z.input;
    int zerr;

    assert(s->type == STREAM_GZIP);
    assert(!s->err);

    if (s->eof || s->eof_pending)
        return 0;

    if (!fill_buffer(src)) {
        s->err = 1;
        return 0;
    }

    z->next_in = src->buf;
    z->avail_in = src->buf_avail;
    z->next_out = buf;
    z->avail_out = size;

    zerr = inflate(z, Z_SYNC_FLUSH);
    if (zerr < 0) {
        s->err = 1;
        return 0;
    }
    if (zerr == Z_STREAM_END)
        s->eof_pending = 1;
    consume(src, src->buf_avail-z->avail_in);

    return size-z->avail_out;
}

void z_stream_close(struct streambuf *s)
{
    assert(s->type == STREAM_GZIP);

    if (s->src.z.zstrm) {
        inflateEnd(s->src.z.zstrm);
        free(s->src.z.zstrm);
        s->src.z.zstrm = NULL;
    }
}

int skip_to_gzip_magic(struct streambuf *s)
{
    static char magic[] = { 0x1f, 0x8b, 0x08 };
    static int magic_len = sizeof(magic);

    while (1) {
        if (!fill_buffer(s))
            return 0;
        while (s->buf_avail >= sizeof(magic)) {
            char *p = memchr(s->buf, magic[0], s->buf_avail-magic_len+1);
            if (!p) {
                consume(s, s->buf_avail-magic_len+1);
                break;
            }
            if (memcmp(p, magic, magic_len) == 0) {
                consume(s, p-s->buf);
                return 1;
            }
            consume(s, p-s->buf+1);
        }
        if (s->eof_pending) {
            consume(s, s->buf_avail);
            return 0;
        }
    }
    /* not reached */
}

int skip_gzip_header(struct streambuf *s)
{
    int flags;

    if (!fill_buffer(s))
        return 0;

    flags = s->buf[3];
    consume(s, 10); /* 10 == basic gzip header size */
    if (flags & EXTRA_FIELD) {
        int extra = ((unsigned char)s->buf[1]<<8)+(unsigned char)s->buf[0];
        consume(s, extra+2);
    }
    if (flags & ORIG_NAME) {
        char *p = memchr(s->buf, '\0', s->buf_avail);
        if (p)
            consume(s, p-s->buf);
    }
    if (flags & COMMENT) {
        char *p = memchr(s->buf, '\0', s->buf_avail);
        if (p)
            consume(s, p-s->buf);
    }
    if (flags & HEAD_CRC)
        consume(s, 2);

    return 1;
}

int try_zlib_init(struct streambuf *s)
{
    struct streambuf *src = s->src.z.input;
    z_streamp z = s->src.z.zstrm;
    int zerr;

    if (!fill_buffer(src))
        goto err_input;

    z->zalloc = zlib_alloc;
    z->zfree = zlib_free;

    z->next_in = src->buf;
    z->avail_in = src->buf_avail;
    z->next_out = s->buf;
    z->avail_out = s->buf_size;

    /* give negative window size to inflateInit2, because gzip files do
     * not contain zlib headers which are expected otherwise */
    if ((zerr = inflateInit2(z, -MAX_WBITS)) != Z_OK)
        goto err_zinit;

    zerr = inflate(z, Z_SYNC_FLUSH);
    if (zerr < 0)
        goto err_decomp;

    s->buf_avail = s->buf_size-z->avail_out;
    if (zerr == Z_STREAM_END)
        s->eof_pending = 1;
    consume(src, src->buf_avail-z->avail_in);

    return 1;

err_decomp:
    inflateEnd(z);
err_zinit:
    consume(src, 1);
err_input:
    return 0;
}

struct streambuf *z_stream_new(struct streambuf *src)
{
    struct streambuf *s;
    z_streamp z;

    s = alloc_stream();

    s->type = STREAM_GZIP;

    s->read = z_stream_read;
    s->close = z_stream_close;

    s->src.z.input = src;
    z = calloc(1, sizeof(z_stream));
    if (z == NULL)
        FATAL("malloc");
    s->src.z.zstrm = z;

    while (skip_to_gzip_magic(src)) {
        if (!skip_gzip_header(src))
            break;
        if (try_zlib_init(s))
            return s; /* we got the zlib stream up and running, cross fingers... */
        if (src->err)
            break;
    }

    /* no gzip data to work on found (or source error...) */
    free(z);
    free_stream(s);
    return NULL;
}

void z_stream_finish(struct streambuf *s)
{
    assert(s->type == STREAM_GZIP);

    while (!s->eof && !s->err) {
        consume(s, s->buf_avail);
        fill_buffer(s);
    }

    consume(s, s->buf_avail);
}

void dump_stream(struct streambuf *s, int fd)
{
    do {
        write(fd, s->buf, s->buf_avail);
        consume(s, s->buf_avail);
        fill_buffer(s);
    } while (!s->eof && !s->err);
}

int is_config(struct streambuf *s)
{
    static char magic[] = "CONFIG_";
    static int magic_len = sizeof(magic)-1;
    char *p;

    if ((p = memchr(s->buf, magic[0], s->buf_avail-magic_len)) != NULL)
        if (memcmp(p, magic, magic_len) == 0)
            return 1;
    return 0;
}

int dump_if_config(struct streambuf *s)
{
    if (!fill_buffer(s))
        return 0;
    if (is_config(s)) {
        dump_stream(s, STDOUT_FILENO);
        if (s->err) {
            error("Error dumping config data: %s\n", s->src.z.zstrm->msg);
            exit(EXIT_FAILURE);
        }
        return 1;
    }
    return 0;
}

int extract_config(const char *fname)
{
    struct streambuf *f, *v, *c;
    int ret = 1;

    f = v = c = NULL;

    /* open outmost stream directly reading from file */
    f = file_stream_new(fname);
    if (f == NULL)
        return 0;

    /* outer gzip encoding... */
    while ((v = z_stream_new(f)) != NULL) {
        if (dump_if_config(v))
            goto cleanup;
        /* inner gzip encoding... */
        while ((c = z_stream_new(v)) != NULL) {
            if (dump_if_config(c))
                goto cleanup;
            z_stream_finish(c);
            close_stream(c);
        }
        z_stream_finish(v);
        close_stream(v);
    }

    error("No config data found.\n"
          "Did you enable CONFIG_PROC_CONFIG and CONFIG_PROC_CONFIG_GZ?\n");
    ret = 0;

cleanup:
    if (c)
        close_stream(c);
    if (v)
        close_stream(v);
    if (f)
        close_stream(f);
    return ret;
}

void usage(const char *me)
{
    fprintf(stderr, "Usage: %s [kernelimage]\n", me);
    exit(EXIT_SUCCESS);
}

int main(int argc, char *argv[])
{
    if (argc > 2)
        usage(argv[0]);
    if (argc == 2) {
        if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-h") == 0)
            usage(argv[0]);
        return !extract_config(argv[1]);
    }
    /* no filename, use stdin */
    return !extract_config(NULL);
}

/*
 * vi:ts=4 sw=4 expandtab
 * vi:tags=./tags,./../tags,./../../tags,tags,../tags,../../tags
 */

Re: How to check the kernel compile options ?

[Randy.Dunlap]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1886 bytes --]

On Tue, 26 Feb 2002, Andreas Ferber wrote:

| On Sat, Feb 23, 2002 at 08:02:24AM +0100, Andreas Ferber wrote:
|
| > At the moment I'm just writing a tool which does all parts in one turn
| > (using zlib), to make it faster and more robust (the script above may
| > fail for example if the kernel image has more than one block of gzip
| > compressed data embedded). (It's actually working already, but the
| > code needs some heavy cleanup before it can be released to the public
| > ;-) Come back in a few days for news...
|
| Here we go again. Attached to this mail you find the announced kernel
| config extractor. It is also available via HTTP:
|
| http://www.myipv6.de/patches/kconfig/dumpkconfig.c

Good!

and here's an alternative, which doesn't put .config in
/proc/ at all, although that's probably better for some
environments or people.

This patch (along with the attached 'binoffset.c' program, which
I didn't stick into linux/scripts/) gives one the option to
have the kernel .config file saved in the kernel image file
(as __initdata) and then use 'extract-ikconfig' to read it from
the kernel image file and re-use it.


Notes:

1.  I didn't zip any of the text since kernel Makefiles (can) do that
on the entire image.

2.  I haven't stripped the leading "CONFIG_" from .config lines.

3.  I strip out (omit) all lines *except* those that begin with
"CONFIG_" or "# CONFIG_".  Keeping the commented CONFIG_ lines
keeps make oldconfig happy.  Otherwise one has to answer for all
unspecified CONFIGs, or use "yes n | make oldconfig" [which is
just as good IMHO, but some users might want to know about new
kernel config options].

4.  The output file from 'extract-ikconfig' contains the CONFIG_
data in reversed order, but oldconfig doesn't care about this.


My test case (.config is around 25000 bytes) increased the
kernel bzImage file size by about 8 KB.

-- 
~Randy

[-- Attachment #2: Type: TEXT/PLAIN, Size: 9609 bytes --]

--- linux/kernel/Makefile.ikc	Sun Sep 16 21:22:40 2001
+++ linux/kernel/Makefile	Thu Feb 28 15:08:20 2002
@@ -19,6 +19,7 @@
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_MODULES) += ksyms.o
 obj-$(CONFIG_PM) += pm.o
+obj-$(CONFIG_IKCONFIG) += configs.o
 
 ifneq ($(CONFIG_IA64),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
@@ -30,3 +31,14 @@
 endif
 
 include $(TOPDIR)/Rules.make
+
+configs.o: $(TOPDIR)/scripts/mkconfigs configs.c
+	echo obj-y == $(obj-y)
+	$(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DEXPORT_SYMTAB -c -o configs.o configs.c
+
+$(TOPDIR)/scripts/mkconfigs: $(TOPDIR)/scripts/mkconfigs.c
+	$(HOSTCC) $(HOSTCFLAGS) -o $(TOPDIR)/scripts/mkconfigs $(TOPDIR)/scripts/mkconfigs.c
+
+configs.c: $(TOPDIR)/.config $(TOPDIR)/scripts/mkconfigs
+	$(TOPDIR)/scripts/mkconfigs $(TOPDIR)/.config configs.c
+
--- linux/arch/i386/defconfig.ikc	Mon Feb 25 11:37:52 2002
+++ linux/arch/i386/defconfig	Thu Feb 28 13:30:39 2002
@@ -103,6 +103,7 @@
 CONFIG_BINFMT_AOUT=y
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
+CONFIG_IKCONFIG=n
 CONFIG_PM=y
 # CONFIG_APM is not set
 
--- linux/arch/i386/config.in.ikc	Mon Feb 25 11:37:52 2002
+++ linux/arch/i386/config.in	Wed Feb 27 13:25:50 2002
@@ -267,6 +267,8 @@
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
 
+bool 'Kernel .config support' CONFIG_IKCONFIG
+
 bool 'Power Management support' CONFIG_PM
 
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
--- linux/scripts/mkconfigs.c.ikc	Wed Feb 27 13:13:30 2002
+++ linux/scripts/mkconfigs.c	Fri Mar  1 09:27:54 2002
@@ -0,0 +1,181 @@
+/***************************************************************************
+ * mkconfigs.c
+ * (C) 2002 Randy Dunlap <rddunlap@osdl.org>
+
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2 of the License, or
+#   (at your option) any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software
+#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+# Rules for scripts/mkconfigs.c input.config output.c
+# to generate configs.c from linux/.config:
+# - drop lines that begin with '#'
+# - drop blank lines
+# - lines that use double-quotes must \\-escape-quote them
+
+################## skeleton configs.c file: ####################
+
+#include <linux/init.h>
+#include <linux/module.h>
+
+static char *configs[] __initdata =
+
+  <insert lines selected lines of .config, quoted, with added '\n'>,
+
+;
+
+################### end configs.c file ######################
+
+ * Changelog for ver. 0.2, 2002-02-15, rddunlap@osdl.org:
+ - strip leading "CONFIG_" from config option strings;
+ - use "static" and "__attribute__((unused))";
+ - don't use EXPORT_SYMBOL();
+ - separate each config line with \newline instead of space;
+
+ * Changelog for ver. 0.3, 2002-02-18, rddunlap@osdl.org:
+ - keep all "not set" comment lines from .config so that 'make *config'
+   will be happy, but don't keep other comments;
+ - keep leading "CONFIG_" on each line;
+
+****************************************************************/
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <errno.h>
+
+#define VERSION		"0.2"
+#define LINE_SIZE	1000
+
+int include_all_lines = 1;	// whether to include "=n" lines in the output
+
+void usage (const char *progname)
+{
+	fprintf (stderr, "%s ver. %s\n", progname, VERSION);
+	fprintf (stderr, "usage:  %s input.config.name path/configs.c\n",
+			progname);
+	exit (1);
+}
+
+void make_intro (FILE *sourcefile)
+{
+	fprintf (sourcefile, "#include <linux/init.h>\n");
+	fprintf (sourcefile, "#include <linux/module.h>\n");
+	fprintf (sourcefile, "\n");
+/////	fprintf (sourcefile, "char *configs[] __initdata = {\n");
+	fprintf (sourcefile, "static char __attribute__ ((unused)) *configs[] __initdata = {\n");
+	fprintf (sourcefile, "  \"CONFIG_BEGIN=n\\n\" ,\n");
+}
+
+void make_ending (FILE *sourcefile)
+{
+	fprintf (sourcefile, "  \"CONFIG_END=n\\n\"\n");
+	fprintf (sourcefile, "};\n");
+/////	fprintf (sourcefile, "EXPORT_SYMBOL (configs);\n");
+}
+
+void make_lines (FILE *configfile, FILE *sourcefile)
+{
+	char cfgline[LINE_SIZE];
+	char *ch;
+
+	while (fgets (cfgline, LINE_SIZE, configfile)) {
+		/* kill the trailing newline in cfgline */
+		cfgline[strlen (cfgline) - 1] = '\0';
+
+		/* don't keep #-only line or an empty/blank line */
+		if ((cfgline[0] == '#' && cfgline[1] == '\0') ||
+		    cfgline[0] == '\0')
+			continue;
+
+		if (!include_all_lines &&
+		    cfgline[0] == '#') // strip out all comment lines
+			continue;
+
+		/* really only want to keep lines that begin with
+		 * "CONFIG_" or "# CONFIG_" */
+		if (strncmp (cfgline, "CONFIG_", 7) &&
+		    strncmp (cfgline, "# CONFIG_", 9))
+		    	continue;
+
+		/*
+		 * use strchr() to check for "-quote in cfgline;
+		 * if not found, output the line, quoted;
+		 * if found, output a char at a time, with \\-quote
+		 * preceding double-quote chars
+		 */
+		if (!strchr (cfgline, '"')) {
+			fprintf (sourcefile, "  \"%s\\n\" ,\n", cfgline);
+			continue;
+		}
+
+		/* go to char-at-a-time mode for this config and
+		 * precede any double-quote with a backslash */
+		fprintf (sourcefile, "  \"");	/* lead-in */
+		for (ch = cfgline; *ch; ch++) {
+			if (*ch == '"')
+				fputc ('\\', sourcefile);
+			fputc (*ch, sourcefile);
+		}
+		fprintf (sourcefile, "\\n\" ,\n");
+	}
+}
+
+int make_configs (FILE *configfile, FILE *sourcefile)
+{
+	make_intro (sourcefile);
+	make_lines (configfile, sourcefile);
+	make_ending (sourcefile);
+}
+
+int main (int argc, char *argv[])
+{
+	char *progname = argv[0];
+	char *configname, *sourcename;
+	FILE *configfile, *sourcefile;
+
+	if (argc != 3)
+		usage (progname);
+
+	configname = argv[1];
+	sourcename = argv[2];
+
+	configfile = fopen (configname, "r");
+	if (!configfile) {
+		fprintf (stderr, "%s: cannot open '%s'\n",
+				progname, configname);
+		exit (2);
+	}
+	sourcefile = fopen (sourcename, "w");
+	if (!sourcefile) {
+		fprintf (stderr, "%s: cannot open '%s'\n",
+				progname, sourcename);
+		exit (2);
+	}
+
+	make_configs (configfile, sourcefile);
+
+	if (fclose (sourcefile)) {
+		fprintf (stderr, "%s: error %d closing '%s'\n",
+				progname, errno, sourcename);
+		exit (3);
+	}
+	if (fclose (configfile)) {
+		fprintf (stderr, "%s: error %d closing '%s'\n",
+				progname, errno, configname);
+		exit (3);
+	}
+
+	exit (0);
+}
+
+/* end mkconfigs.c */
--- linux/scripts/extract-ikconfig.ikc	Wed Feb 27 13:14:02 2002
+++ linux/scripts/extract-ikconfig	Tue Feb 19 00:17:10 2002
@@ -0,0 +1,17 @@
+#! /bin/bash -x
+# extracts .config info from a [b]zImage file
+# uses: binoffset (new), dd, zcat, strings, grep
+# $arg1 is [b]zImage filename
+
+HDR=`binoffset $1 0x1f 0x8b 0x08 0x0`
+PID=$$
+TMPFILE="$1.vmlin.$PID"
+
+# dd if=$1 bs=1 skip=$HDR | zcat - | strings /dev/stdin \
+# | grep "[A-Za-z_0-9]=[ynm]$" | sed "s/^/CONFIG_/" > $1.oldconfig.$PID
+# exit
+
+dd if=$1 bs=1 skip=$HDR | zcat - > $TMPFILE
+strings $TMPFILE | grep "^[\#[:blank:]]*CONFIG_[A-Za-z_0-9]*" > $1.oldconfig.$PID
+wc $1.oldconfig.$PID
+rm $TMPFILE
--- linux/Documentation/Configure.help.ikc	Wed Feb 27 09:54:42 2002
+++ linux/Documentation/Configure.help	Fri Mar  1 09:13:00 2002
@@ -4958,6 +4958,19 @@
   replacement for kerneld.) Say Y here and read about configuring it
   in <file:Documentation/kmod.txt>.
 
+Kernel .config file saved in kernel image
+CONFIG_IKCONFIG
+  This option enables the complete Linux kernel ".config" file contents
+  to be saved in the kernel (zipped) image file.  It provides
+  documentation of which kernel options are used in a running kernel or
+  in an on-disk kernel.  It can be extracted from the kernel image file
+  with a script and used as input to rebuild the current kernel or to
+  build another kernel.  Since the kernel image is zipped, using this
+  option adds approximately 8 KB to a kernel image file.
+  This option is not available as a module.  If you want a separate
+  file to save the kernel's .config contents, use 'installkernel' or 'cp'
+  or a similar tool, or just save it in '/lib/modules/<kernel-version>'.
+
 ARP daemon support
 CONFIG_ARPD
   Normally, the kernel maintains an internal cache which maps IP
--- linux/Makefile.ikc	Wed Feb 27 09:54:42 2002
+++ linux/Makefile	Thu Feb 28 14:26:09 2002
@@ -194,6 +194,7 @@
 	kernel/ksyms.lst include/linux/compile.h \
 	vmlinux System.map \
 	.tmp* \
+	scripts/mkconfigs kernel/configs.c kernel/configs.o \
 	drivers/char/consolemap_deftbl.c drivers/video/promcon_tbl.c \
 	drivers/char/conmakehash \
 	drivers/char/drm/*-mod.c \
@@ -233,6 +234,7 @@
 	include/asm \
 	.hdepend scripts/mkdep scripts/split-include scripts/docproc \
 	$(TOPDIR)/include/linux/modversions.h \
+	scripts/mkconfigs kernel/configs.c kernel/configs.o \
 	kernel.spec
 
 # directories removed with 'make mrproper'

[-- Attachment #3: Type: TEXT/PLAIN, Size: 4180 bytes --]

/***************************************************************************
 * binoffset.c
 * (C) 2002 Randy Dunlap <rddunlap@osdl.org>

#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

# binoffset.c:
# - searches a (binary) file for a specified (binary) pattern
# - returns the offset of the located pattern or ~0 if not found
# - exits with exit status 0 normally or non-0 if pattern is not found
#   or any other error occurs.

****************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#define VERSION		"0.1"
#define BUF_SIZE	(16 * 1024)
#define PAT_SIZE	100

char		*progname;
char		*inputname;
int		inputfd;
int		bix;			/* buf index */
unsigned char	patterns [PAT_SIZE] = {0}; /* byte-sized pattern array */
int		pat_len;		/* actual number of pattern bytes */
unsigned char	*madr;			/* mmap address */
size_t		filesize;
int		num_matches = 0;
off_t		firstloc = 0;

void usage (void)
{
	fprintf (stderr, "%s ver. %s\n", progname, VERSION);
	fprintf (stderr, "usage:  %s filename pattern_bytes\n",
			progname);
	fprintf (stderr, "        [prints location of pattern_bytes in file]\n");
	exit (1);
}

int get_pattern (int pat_count, char *pats [])
{
	int ix, err, tmp;

#ifdef DEBUG
	fprintf (stderr,"get_pattern: count = %d\n", pat_count);
	for (ix = 0; ix < pat_count; ix++)
		fprintf (stderr, "  pat # %d:  [%s]\n", ix, pats[ix]);
#endif

	for (ix = 0; ix < pat_count; ix++) {
		tmp = 0;
		err = sscanf (pats[ix], "%5i", &tmp);
		if (err != 1 || tmp > 0xff) {
			fprintf (stderr, "pattern or value error in pattern # %d [%s]\n",
					ix, pats[ix]);
			usage ();
		}
		patterns [ix] = tmp;
	}
	pat_len = pat_count;
}

int search_pattern (void)
{
	for (bix = 0; bix < filesize; bix++) {
		if (madr[bix] == patterns[0]) {
			if (memcmp (&madr[bix], patterns, pat_len) == 0) {
				if (num_matches == 0)
					firstloc = bix;
				num_matches++;
			}
		}
	}
}

#ifdef NOTDEF
size_t get_filesize (int fd)
{
	off_t end_off = lseek (fd, 0, SEEK_END);
	lseek (fd, 0, SEEK_SET);
	return (size_t) end_off;
}
#endif

size_t get_filesize (int fd)
{
	int err;
	struct stat stat;

	err = fstat (fd, &stat);
	fprintf (stderr, "filesize: %d\n", err < 0 ? err : stat.st_size);
	if (err < 0)
		return err;
	return (size_t) stat.st_size;
}

int main (int argc, char *argv [])
{
	progname = argv[0];

	if (argc < 3)
		usage ();

	get_pattern (argc - 2, argv + 2);

	inputname = argv[1];

	inputfd = open (inputname, O_RDONLY);
	if (inputfd == -1) {
		fprintf (stderr, "%s: cannot open '%s'\n",
				progname, inputname);
		exit (3);
	}

	filesize = get_filesize (inputfd);

	madr = mmap (0, filesize, PROT_READ, MAP_PRIVATE, inputfd, 0);
	if (madr == MAP_FAILED) {
		fprintf (stderr, "mmap error = %d\n", errno);
		close (inputfd);
		exit (4);
	}

	search_pattern ();

	if (munmap (madr, filesize))
		fprintf (stderr, "munmap error = %d\n", errno);

	if (close (inputfd))
		fprintf (stderr, "%s: error %d closing '%s'\n",
				progname, errno, inputname);

	fprintf (stderr, "number of pattern matches = %d\n", num_matches);
	if (num_matches == 0)
		firstloc = ~0;
	printf ("%d\n", firstloc);
	fprintf (stderr, "%d\n", firstloc);

	exit (num_matches ? 0 : 2);
}

/* end binoffset.c */

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 13, 2002 10:51 pm, Bill Davidsen wrote:
> On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> 
> > The advantage, of course is that if you are executing the kernel,
> > it can give you all the information necessary to recreate a
> > new one from the sources because its .config is embeded into
> > itself. Once you have the ".config" file, you just do `make oldconfig`
> > and you are home free.
> 
> But it does no such thing! You not only need the config file, you need the
> source.

The source is readily available, the specific config used for your kernel may
not be.

> This feature just isn't all that useful,

Given your little logic slip above I'm not sure I should trust your conclusion.
OK, I'm out of here, I'm not interested in discussing why any more, only how.

-- 
Daniel

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Thu, 14 Feb 2002, Daniel Phillips wrote:

> On February 13, 2002 10:51 pm, Bill Davidsen wrote:
> > On Wed, 13 Feb 2002, Richard B. Johnson wrote:
> > 
> > > The advantage, of course is that if you are executing the kernel,
> > > it can give you all the information necessary to recreate a
> > > new one from the sources because its .config is embeded into
> > > itself. Once you have the ".config" file, you just do `make oldconfig`
> > > and you are home free.
> > 
> > But it does no such thing! You not only need the config file, you need the
> > source.
> 
> The source is readily available, the specific config used for your kernel may
> not be.

So is the prototype config file, what's your point? You need BOTH the
actual config file and the actual kernel source including patches to
really know what happened and to replicate it. As in kernel.org source,
Redhat source, etc. There is no "the source."
 
> > This feature just isn't all that useful,
> 
> Given your little logic slip above I'm not sure I should trust your conclusion.
> OK, I'm out of here, I'm not interested in discussing why any more, only how.

That's the point, you probably only do the very simple stuff, booting from
a multi-GB disk. People who have more complex boot systems want the boot
image small, that's why it was gzipped and later bzipped, so it would fot
more places.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Chris Friesen]

Bill Davidsen wrote:

> I like making it a module because it's obvious that modules_install is
> needed. I see zero added utility from having it part of the kernel or
> nothing, it's useful even to people booting from ROM, small /boot
> partitions, etc.

Not everyone uses modules.  There are a substantial number of people that avoid
modules if possible.  Ideally, it should be possible to make the config options
built in, modular, or not present at all.

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Sat, 9 Feb 2002, Bill Davidsen wrote:

| On Wed, 6 Feb 2002, Randy.Dunlap wrote:
|
| > I still prefer your suggestion to append it to the kernel image
| > as __initdata so that it's discarded from memory but can be
| > read with some tool(s).
|
| The problem is that it make the kernel image larger, which lives in /boot
| on many systems. Putting it in a module directory, even if not a module,
| would be a better place for creative boot methods, of which there are
| many.

Yes, it can add a few KB to a kernel image.
Some people could think that it's worth it...especially
if it's a build option.

I prefer this to using /proc/config.gz (which SuSE currently does),
since the config data won't be in permanent memory, and it's
attached to a kernel image on disk -- the kernel doesn't have to
be loaded in memory to view it.  (or maybe there's a way to
view config.gz in a SuSE kernel image ?)

I don't see how making it a binary module (living in
/lib/modules/version/kernel/configs.o e.g.) has any advantages
over kbuild (?) just copying the .config file to
/lib/modules/2.5.4/.config .

Does anyone recall if kbuild already does something like this?

I spent a little time this weekend making .config live in an
__initdata array, and I can see it in 'vmlinux',
but I can't see it in the (compressed) 'bzImage' file.
I expect that this is just a tools problem, due to the
compressed kernel image.  Does anyone know how to grep
for a string in 'bzImage', or how to expand 'bzImage'
so that grep can find strings in it?

-- 
~Randy

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Mon, 11 Feb 2002, Randy.Dunlap wrote:

> On Sat, 9 Feb 2002, Bill Davidsen wrote:
> 
> | On Wed, 6 Feb 2002, Randy.Dunlap wrote:
> |
> | > I still prefer your suggestion to append it to the kernel image
> | > as __initdata so that it's discarded from memory but can be
> | > read with some tool(s).
> |
> | The problem is that it make the kernel image larger, which lives in /boot
> | on many systems. Putting it in a module directory, even if not a module,
> | would be a better place for creative boot methods, of which there are
> | many.
> 
> Yes, it can add a few KB to a kernel image.
> Some people could think that it's worth it...especially
> if it's a build option.

The capability is definitely desirable, I think it's just implementation
being discussed.
 
> I prefer this to using /proc/config.gz (which SuSE currently does),
> since the config data won't be in permanent memory, and it's
> attached to a kernel image on disk -- the kernel doesn't have to
> be loaded in memory to view it.  (or maybe there's a way to
> view config.gz in a SuSE kernel image ?)
> 
> I don't see how making it a binary module (living in
> /lib/modules/version/kernel/configs.o e.g.) has any advantages
> over kbuild (?) just copying the .config file to
> /lib/modules/2.5.4/.config .

There are already uncompressed pure text files in the modules directory,
such as modules.dep. Adding one more is probably not a space issue on most
systems, while kernel size may be, since it has to be present at boot.

I don't have any issue with allowing a symbolic link in /proc down to the
config, if people want it there. I always Slink the /lib/modules/xxx dir
to /boot/Modules and the current symbols to /boot/System.map as well.
Links in known places are good.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[Ville Herva]

On Wed, Feb 06, 2002 at 02:16:27PM +0000, you [Alan Cox] wrote:
> > > If you are going to cat it onto the end of the kernel image just
> > > mark it __initdata and shove a known symbol name on it. It'll get
> > > dumped out of memory and you can find it trivially by using tools on
> > > the binary
> > 
> > What about putting such info into a (swappable) tmpfs file with
> > shmem_file_setup?
> 
> That is indeed an extremely cunning plan. Paticularly as /proc/config can
> be a symlink to it

What is even harder to find out given a binary kernel is which patches (if
any) have been applied to it. What if there was one file (say,
/usr/src/linux/patches) to which each (well-behaved) patch would append a
line or two (patch name, version, author, url), and then you could later
extract that information the same way you extract .config?

Figuring out what patches have been applied can be hard even given a source
tree, so this could be useful even without the data-in-bzImage thing.


-- v --

v@iki.fi

Re: How to check the kernel compile options ?

[Thomas Capricelli]

> What is even harder to find out given a binary kernel is which patches (if
> any) have been applied to it. What if there was one file (say,
> /usr/src/linux/patches) to which each (well-behaved) patch would append a
> line or two (patch name, version, author, url), and then you could later
> extract that information the same way you extract .config?

	I second that. It would be great to have a way of knowing what's different 
from vanillia kernel. though:

	* we can't expect each patch to do the 'magic thing'. But at least, those 
big patches lying around could follow this kind of rule. I don't care about 
typos patches, but It would be great to know that (for ex.) the rmap patch is 
there or not.

	* having /usr/src/linux/patches is not practical : it will be a big mess wrt 
to conflict

	The reason why I have not proposed something already is that I have no clue 
how to achieve this purpose. But I still would like to have a way to know 
which big patches have been in my kernel.


sorry,
Thomas

Re: How to check the kernel compile options ?

[David Relson]

At 12:26 PM 2/6/02, you wrote:


>... snip ...
>
>         * having /usr/src/linux/patches is not practical : it will be a 
> big mess wrt
>to conflict

Indeed, if /usr/src/linux/patches was a file, the conflicts would be 
impossible to manage.  But suppose it was a directory and each patch 
created a small description file in that directory.  This would provide the 
desired information without having the big mess :-)

It's been suggested that config info be saved using the following:

         <.config sed -e '/^#/d' -e '/^[    ]*$/d' | gzip -9 >> image

The patch descriptions could be saved in a similar manner:

         cat /usr/src/linux/patches/* | gzip -9 >> image

Alternatively, instead of outputting to image, one could output to 
/boot/patch-$KERNELVERSION, (or wherever)

David

Re: How to check the kernel compile options ?

[Ville Herva]

On Wed, Feb 06, 2002 at 01:16:58PM -0500, you [David Relson] wrote:
> At 12:26 PM 2/6/02, you wrote:
> 
> 
> >... snip ...
> >
> >        * having /usr/src/linux/patches is not practical : it will be a 
> >big mess wrt
> >to conflict
> 
> Indeed, if /usr/src/linux/patches was a file, the conflicts would be 
> impossible to manage.  But suppose it was a directory and each patch 
> created a small description file in that directory.  This would provide the 
> desired information without having the big mess :-)

With a directory, you lose the information of in which order the patches
have been applied - unless of course you resort to file dates or some such.

I agree that one file is very problematic wrt. patch(1), but I was hoping
there would be a way to persuade patch into doing the right thing.

Anyway, I think these kind of issues are solveable if only anybody agrees
this is a good idea...
 
> The patch descriptions could be saved in a similar manner:
> 
>         cat /usr/src/linux/patches/* | gzip -9 >> image
> 
> Alternatively, instead of outputting to image, one could output to 
> /boot/patch-$KERNELVERSION, (or wherever)

Yep.

To get back to the original subject: I often compile test kernels and use a
ext2 fs on a cdr as the root fs. I put the tested kernel on a floppy (1)
with cp bzImage /dev/fd0. And then when I finally come up with something
interested I usually find my self pondering is this this or that kernel on
this floppy... In that case the /proc/config thing (and /proc/patches or
whatever) is very useful.

(I admit I should be using lilo on the floppy, and the next problem I hit is
finding the right System.map, which /proc/* won't solve, but...)


-- v --

v@iki.fi

(1) Is there a way to make ext2 fs cd bootable? I know I can do that with
iso fs cd (with the el torido boot image), but I've found no way to do that
with other filesystems.

Re: How to check the kernel compile options ?

[Thomas Capricelli]

> Anyway, I think these kind of issues are solveable if only anybody agrees
> this is a good idea...

	I for sur agree. Especially if we consider the practical approach :
	Not all patches are required to add the file under linux/patches/, but good 
ones will
	Probability that such thing happen is almost 0, big kernel guys aren't even 
reading this thread :(. I won't loose my time trying ot make this happen as 
they wont even consider reading about such things.  too bad :(


Thomas

Re: How to check the kernel compile options ?

[Ville Herva]

On Thu, Feb 07, 2002 at 10:12:12AM +0100, you [Thomas Capricelli] wrote:
>  
> > Anyway, I think these kind of issues are solveable if only anybody agrees
> > this is a good idea...
> 
> 	I for sur agree. Especially if we consider the practical approach :
> 	Not all patches are required to add the file under linux/patches/,
> 	but good ones will
> 	Probability that such thing happen is almost 0, big kernel guys
> aren't even reading this thread :(. I won't loose my time trying ot make
> this happen as they wont even consider reading about such things.  too bad
> :(

Yes. The problem is that Linux/Alan/Marcelo or who ever maintains proper
kernel trees aren't interested - the /usr/src/linux/patches stuff is only on
the way for them. (Although they could easily rm -rf /usr/src/linux/patches
before making a release if they please.)

This idea is mostly applicable to external patches not ment for inclusion
(yet).

Maybe if there was a well-defined framework, we could persuade some of the
most influential patch maintainers (Rik van Riel, Robert Love, Andre Hedrick
etc..) use it. Then maybe, big maybe, it might catch fire.


-- v --

v@iki.fi

Re: How to check the kernel compile options ?

[Horst von Brand]

Ville Herva <vherva@niksula.hut.fi> said:

[...]

> With a directory, you lose the information of in which order the patches
> have been applied - unless of course you resort to file dates or some
> such.

Pfui! Think patches 1, 2, 3 in this order; with 2a later superseeding 2...

> I agree that one file is very problematic wrt. patch(1), but I was hoping
> there would be a way to persuade patch into doing the right thing.

They do it in RPM's spec files, listing the patches (and saying if, and
perhaps when, in what order) they have to be applied. A source RPM is not
that much more than a cpio(1)-ball of the sources, patches, and .spec, very
handy a  _single_ file.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: How to check the kernel compile options ?

[Ville Herva]

On Thu, Feb 07, 2002 at 10:11:44PM +0100, you [Horst von Brand] wrote:
> Ville Herva <vherva@niksula.hut.fi> said:
> 
> [...]
> 
> > With a directory, you lose the information of in which order the patches
> > have been applied - unless of course you resort to file dates or some
> > such.
> 
> Pfui! Think patches 1, 2, 3 in this order; with 2a later superseeding 2...

Well, what way 2a supersedes 2? diff-2-2a? That would add a "2-2a" entry to
the patches dir.

But clearly this scheme is not suited for nor aimed at maintaining a tree.
It is more useful when you build a kernel from already existing bits: I
usually take stable tree X, then pre-patch Y, ac- or aa- patch Z and stuff
like newer raid/lvm patch, ide-patch, reiserfs patch, e2compr patch,
lowlatency patch etc. Later I have trouble remembering which patches went in
to that particular kernel (and which versions of those patches.)
 
> They do it in RPM's spec files, listing the patches (and saying if, and
> perhaps when, in what order) they have to be applied. A source RPM is not
> that much more than a cpio(1)-ball of the sources, patches, and .spec, very
> handy a  _single_ file.

Yes, perhaps I should make rpm out of each kernel I build - but then again
that won't help with boot disks nor with non-redhat systems.


-- v --

v@iki.fi

Re: How to check the kernel compile options ?

[Horst von Brand]

Alan Cox <alan@lxorguk.ukuu.org.uk> said:
> "Christoph Rohland" at Feb 06, 2002 11:36:56 AM said:
> X-Mailer: ELM [version 2.5 PL6]
> MIME-Version: 1.0
> Sender:  linux-kernel-owner@vger.kernel.org
> Precedence: bulk
> X-Mailing-List: linux-kernel@vger.kernel.org
> X-UIDL:  70dcc828dc0f5fc32828144e3bf3c08c
> 
> > > If you are going to cat it onto the end of the kernel image just
> > > mark it __initdata and shove a known symbol name on it. It'll get
> > > dumped out of memory and you can find it trivially by using tools on
> > > the binary
> > 
> > What about putting such info into a (swappable) tmpfs file with
> > shmem_file_setup?
> 
> That is indeed an extremely cunning plan. Paticularly as /proc/config can
> be a symlink to it

Right. If I take my .config, get just non-"n" entries, get rid of the
CONFIG_ at each line, then gzip(1) the result, I get 1515 _bytes_. Less
than the rounding error in a module, can be expanded on the fly with
existing infrastructure.

Sure, it makes sense to have .config around somehow for some rather
specialized cases, but kludgeing on some such functionality for a very
niche use just stinks, IMHO.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: How to check the kernel compile options ?

[Marco Colombo]

On Wed, 6 Feb 2002 Andries.Brouwer@cwi.nl wrote:

>     > I would be surprised if there is anyone on this list
>     > who has not lost at some point either the .config, the
>     > ksyms, or something similar associated with at least
>     > one build they've made.
> 
>     Sure.  And people have lost their root filesystems due to "rm -rf /".
>     That doesn't mean we build the entire (real) root filesystem into
>     the kernel.
> 
> 	-hpa
> 
> Peter, in my eyes this is an unreasonable answer.
> 
> For debugging and other purposes it is good to have some
> information. One may wish to know about a certain kernel image
> what Linux kernel version that was, with what patches, compiled
> with what options, by which compiler. Or one may want to know
> such things about the currently running kernel. Even user-space
> programs (like mount) may want to know (what NFS version? do we
> have CONFIG_JOLIET?).

No, applications already can (should) recover from a "missing feature"
error, after executing some syscall. Even if your .config says you've
compile the scsi tape driver into the running kernel, it doesn't mean
there is a scsi tape attached somewhere. And if your kernel is modular,
how can an application tell if some module is avalable? .config may
say that feature was compliled as a module, but has no knowledge of the
binary module being accessible or not.

> Today we supply a little of this information.
> For example, /proc/version supplies information on version
> and compiler and date. Why? One might as well keep this compiler
> info in a separate file. What a waste of unswappable kernel memory!

You have a point here, IMHO.

$ cat /proc/version
Linux version 2.4.9-21 (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 Thu Jan 17 13:35:37 EST 2002

email addresses, compiler versions, distro release strings, build dates,
all belongs to the same place of .config.  And all are retrievable 
performing rpm -qi. And overall less useful than .config.

Uh, but wait, that's RH bloat... B-)

> You see - this is not a matter of absolutes.
> In the good old days, when an operating system had to fit in 4k
> and a device driver in 128 words, putting a 100-char text like
> the one found in /proc/version into the system would be ridiculous.
> Today nobody worries about a hundred bytes paid for some useful info.
> 
> So, the question is: how useful is the information, and how expensive
> is it to store it. Consider the config options. How much space do they
> take? Typically 1-5 kB (compressed). If this is stored at the end of
> a kernel image file, and not loaded into memory, then the kernel memory
> cost is zero. If this is made part of the kernel itself, say accessible
> via /proc, then the cost is 1-5 kB.

No, the question is why you need to bury this info into the kernel.
The information *is* available, unless you delete it (or forget to save
it, or use the wrong tool to install the kernel, and so on).

> So, you should ponder whether it is worthwhile to pay this cost of zero,
> and ponder whether it is worthwhile to pay this cost of 5 kB.

To gain what? To recover it if someone deletes 
/lib/modules/`uname -r`/config.gz (or /boot/config-`uname -r`.gz)?

> Andries

.TM.

Re: How to check the kernel compile options ?

[Horst von Brand]

Marco Colombo <marco@esi.it> said:

[...]

> No, applications already can (should) recover from a "missing feature"
> error, after executing some syscall. Even if your .config says you've
> compile the scsi tape driver into the running kernel, it doesn't mean
> there is a scsi tape attached somewhere. And if your kernel is modular,
> how can an application tell if some module is avalable? .config may
> say that feature was compliled as a module, but has no knowledge of the
> binary module being accessible or not.

.config might even say there is no support for <foo>, but there is in the
form of a third-party module addon. The only way out is to try and recover
if it fails.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: How to check the kernel compile options ?

[Paul Menage]

In article <0C01A29FBAE24448A792F5C68F5EA47D217218@nasdaq.ms.ensim.com>,
you write:
>The reason you need all of these config options (which don't end up
>making the code much more complex) is because, for example, if you
>are netbooting your kernel, you do not have access to any external
>data or even the original kernel image on that system.  If it is
>in-memory
>you use 15kB of RAM (5kB in the compressed image) for a fully-configured
>vendor kernel, but you have the config options for THIS kernel and not
>any "maybe it is right, maybe not" external file.

How about having the MD5 sum of the config printed during boot time,
just after (or on) the "Linux version" line - then at least you'd be
able to verify that the .config file in your hands was indeed the one
that was used to compile the kernel.

Paul

Re: How to check the kernel compile options ?

[Rick A. Hohensee]

The following is my original post on "make appendage" and some other
goodies you'll find in cLIeNUX, assuming you can find cLIeNUX. Perhaps it
would have recieved more play at the time if the subject line had been 

make state relink Linux appendage

The real reason I repeat posts like this though is I look at them later
and *I* can't readily see what I'm talking about. Oops.

make state   snags the state of the shell and make environment for the
build. You need a hook in the makefile to get it.

Make relink   allows a quick rebuild after one small source file edit
somewhere by zapping all the per-dir lib.o's and other rebuild snaggers.

make Linux   saves newbies (We are all newbies) from having the
arch/bla/compressed/actual.img    "learning" experience and not trying to
boot vmlinuz.

make appendage   is the part that this thread resembles.

Other cLIeNUXisms are the 2-line Bash prompt, here in tawdry monochrome, 
and the DISTRO shell variable.


            make state ; make relink ; make Linux ; make appendage

   From: Rick Hohensee ([1]humbubba@smarty.smart.net)
   Date: Mon Apr 10 2000 - 01:00:10 EST

     * Next message: [2]Web Administrator: "Re: /proc/net/dev reporting
       on virtual interfaces"
     * Previous message: [3]Eric W. Biederman: "Re: Suggested dual
       human/binary interface for proc/devfs"
     * Messages sorted by: [4][ date ] [5][ thread ] [6][ subject ] [7][
       author ]
     _________________________________________________________________

   cd linux

   The next 2 lines are an occurance of my Bash prompt...
   :; cLIeNUX0 /dev/tty4 r 20:08:30 /source/core/KERNEL/linux
   :;<cursor here>

   step-wise demo. Elapsed times per $PS1 are not quite realistic.
   ..................................................................
   :; cLIeNUX0 /dev/tty4 r 20:08:30 /source/core/KERNEL/linux
   :;make state
   set > .make_state
   :; cLIeNUX0 /dev/tty4 r 20:10:39 /source/core/KERNEL/linux
   :;cat .make_state
   AR=ar
   ARCH=i386
   AS=as
   AWKPATH=/source/script/awk
   BASH=/.bi/sh
   BASH_VERSINFO=([0]="2" [1]="02" [2]="0" [3]="1" [4]="release"
   [5]="i4<snip>
   BASH_VERSION='2.02.0(1)-release'
   CC='gcc -D__KERNEL__ -I/source/core/KERNEL/linux/include'
   CFLAGS='-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
   -fno-s<snip>
   CFLAGS_NSR=-fno-strength-reduce
   CFLAGS_PIPE=-pipe
   COMPILER_PATH='~:/.roo/command:/.bi:/.sbi:/.bi/unix/:.:/.bi/background
   /C/'
   CONFIG_1GB=y
   CONFIG_M386=y
   CONFIG_SHELL=/.bi/sh
   CORE_FILES='arch/i386/kernel/kernel.o arch/i386/mm/mm.o
   kernel/kerne<snip>
   fs/fs.o ipc/ipc.o'
   CPP='gcc -D__KERNEL__ -I/source/core/KERNEL/linux/include -E'
   CROSS_COMPILE=
   C_INCLUDE_PATH=/.bi/background/C/include:/source/C/include/:/suit<snip
   >
   DIRSTACK=()
   DISTRO=cLIeNUX
   <snip>

   :; cLIeNUX0 /dev/tty4 r 20:10:39 /source/core/KERNEL/linux
   :;make relink

   rm -v /source/core/KERNEL/linux/arch/i386/boot/bzImage
   /source/core/KERNEL/linux/arch/i386/boot/zImage
   /source/core/KERNEL/linux/vmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux.out
   /source/core/KERNEL/linux/arch/i386/boot/compressed/piggy.o
   /source/core/KERNEL/linux/Linux arch/i386/kernel/kernel.o
   arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o
   fs/filesystems.a net/network.a \
           drivers/block/block.a drivers/char/char.a drivers/misc/misc.a
   drivers/net/net.a /source/core/KERNEL/linux/arch/i386/lib/lib.a
   /source/core/KERNEL/linux/lib/lib.a
   /source/core/KERNEL/linux/arch/i386/lib/lib.a
   /source/core/KERNEL/linux/arch/i386/boot/bzImage
   /source/core/KERNEL/linux/arch/i386/boot/zImage
   /source/core/KERNEL/linux/vmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux.out
   /source/core/KERNEL/linux/arch/i386/boot/compressed/piggy.o
   /source/core/KERNEL/linux/Linux
   rm: /source/core/KERNEL/linux/arch/i386/boot/bzImage: No such file or
   directory
   rm: /source/core/KERNEL/linux/arch/i386/boot/zImage: No such file or
   directory
   /source/core/KERNEL/linux/vmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux
   /source/core/KERNEL/linux/arch/i386/boot/compressed/bvmlinux.out
   /source/core/KERNEL/linux/arch/i386/boot/compressed/piggy.o
   /source/core/KERNEL/linux/Linux
   arch/i386/kernel/kernel.o
   arch/i386/mm/mm.o
   kernel/kernel.o
   mm/mm.o
   fs/fs.o
   ipc/ipc.o
   fs/filesystems.a
   net/network.a
   drivers/block/block.a
   drivers/char/char.a
   drivers/misc/misc.a
   drivers/net/net.a
   /source/core/KERNEL/linux/arch/i386/lib/lib.a
   /source/core/KERNEL/linux/lib/lib.a
   make: [relink] Error 1 (ignored)
   :; cLIeNUX0 /dev/tty4 r 20:10:39 /source/core/KERNEL/linux
   :;make Linux
   make -C kernel
   make[1]: Entering directory `/source/core/KERNEL/linux/kernel'
   make all_targets
   make[2]: Entering directory `/source/core/KERNEL/linux/kernel'
   rm -f kernel.o
   ld -m elf_i386 -r -o kernel.o signal.o sched.o dma.o fork.o exe<snip>
   make[2]: Leaving directory `/source/core/KERNEL/linux/kernel'
   make[1]: Leaving directory `/source/core/KERNEL/linux/kernel'
   make -C drivers
   make[1]: Entering directory `/source/core/KERNEL/linux/drivers'
   make -C block
   make[2]: Entering directory `/source/core/KERNEL/linux/drivers/block'
   make all_targets
   make[3]: Entering directory `/source/core/KERNEL/linux/drivers/block'
   rm -f block.a
   ar rcs block.a ll_rw_blk.o genhd.o
   make[3]: Leaving directory `/source/core/KERNEL/linux/drivers/block'

   < ... much more re-linking and no actual compiling snipped...>

   Root device is (8, 1)
   Boot sector 512 bytes.
   Setup is 1288 bytes.
   System is 154 kB
   make[1]: Leaving directory `/source/core/KERNEL/linux/arch/i386/boot'
   mv /source/core/KERNEL/linux/arch/i386/boot/bzImage
   /source/core/<snip>
   :; cLIeNUX0 /dev/tty4 r 20:20:19 /source/core/KERNEL/linux
   :;make appendage
   set > .make_state
   echo -e "\n\nCONFIG_>> .config appendage..." >> /source/c
   grep -v "^#" /source/core/KERNEL/linux/.config >> /source/core/K<snip>
   echo -e "\nCONFIG_>> .make_state appendage..." >>
   /source/core/KERNE<snip>
   cat /source/core/KERNEL/linux/.make_state >>
   /source/core/KERNEL/linux/Linux
   :; cLIeNUX0 /dev/tty4 r 20:22:09 /source/core/KERNEL/linux
   :;grep CONFIG Linux
   Binary file Linux matches
   :; cLIeNUX0 /dev/tty4 r 20:22:25 /source/core/KERNEL/linux
   :;grep -a CONFIG Linux
   CONFIG_>> .config appendage...
   CONFIG_M386=y
   CONFIG_1GB=y
   CONFIG_>> .make_state appendage...
   CONFIG_1GB=y
   CONFIG_M386=y
   CONFIG_SHELL=/.bi/sh
   :; cLIeNUX0 /dev/tty4 r 20:22:32 /source/core/KERNEL/linux
   :;
   ....................................................................

   caused by...
           in linux/Makefile...
                   ..................................................
   relink:
           -rm -v $(IMAGES) $(CORE_FILES) $(FILESYSTEMS) $(NETWORKS) \
                   $(DRIVERS) $(LIBS)

   state:
           set > .make_state

   ................................................................
           In linux/arch/i386/Makefile...

                   ................................................

   IMAGES =$(TOPDIR)/arch/$(ARCH)/boot/bzImage \
                    $(TOPDIR)/arch/$(ARCH)/boot/zImage \
                    $(TOPDIR)/vmlinux \
                    $(TOPDIR)/arch/$(ARCH)/boot/compressed/bvmlinux \
                    $(TOPDIR)/arch/$(ARCH)/boot/compressed/bvmlinux.out \
                    $(TOPDIR)/arch/$(ARCH)/boot/compressed/piggy.o \
                    $(TOPDIR)/Linux

   Linux: bzImage
           mv $(TOPDIR)/arch/$(ARCH)/boot/bzImage $(TOPDIR)/Linux

   append appendage: state
           -echo -e "\n\nCONFIG_>> .config appendage..." >>
   $(TOPDIR)/Linux
           -grep -v "^#" $(TOPDIR)/.config >> $(TOPDIR)/Linux
           -echo -e "\nCONFIG_>> .make_state appendage..." >>
   $(TOPDIR)/Linux
           -cat $(TOPDIR)/.make_state >> $(TOPDIR)/Linux

   ......................................................................
   .

   I wasn't going to bother with make targets for these, not being real
   fond
   of make anyway, until I saw that the variables in the relink: target
   except for IMAGES already exist.

                           Cordially,

                                   Rick Hohensee

r

Re: How to check the kernel compile options ?

[Giacomo Catenazzi]

David Balazic wrote:

> Hi!
> 
> This problem again :-)
> 
> I purchase/download a program for linux.
> It says it requires certain kernel features, for example :
> CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET
> 
> How can I figure out in 5 minutes, without a kernel hacker, if
> my linux system has the correct settings ?
> 
> This is a real life question, probably more suitable to ask
> on some distributions mail list, but I thought I'll start here.


I agree: ask to yout distribution mail list. Every distribution
have a different place for kernel configuration.

Anyway:
If you use your distribution kernel, and if your distribution is
not so strange, you have enabled the 3 drivers.

	giacomo

 

How to check the kernel compile options ?

[David Balazic]

Hi!

This problem again :-)

I purchase/download a program for linux.
It says it requires certain kernel features, for example :
CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET

How can I figure out in 5 minutes, without a kernel hacker, if
my linux system has the correct settings ?

This is a real life question, probably more suitable to ask
on some distributions mail list, but I thought I'll start here.

TIA,
david

P.S.: Please CC me on the answers.

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How to check the kernel compile options ?

[Alan Cox]

> I purchase/download a program for linux.
> It says it requires certain kernel features, for example :
> CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET
> 
> How can I figure out in 5 minutes, without a kernel hacker, if
> my linux system has the correct settings ?

Use the vendor supplied kernels ?

Re: How to check the kernel compile options ?

[David Balazic]

Alan Cox wrote:
> 
> > I purchase/download a program for linux.
> > It says it requires certain kernel features, for example :
> > CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET
> >
> > How can I figure out in 5 minutes, without a kernel hacker, if
> > my linux system has the correct settings ?
> 
> Use the vendor supplied kernels ?

Yes, I am using them.
Now back to my question, how do I found out if option X is set or not ?

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How to check the kernel compile options ?

[Alan Cox]

> > > How can I figure out in 5 minutes, without a kernel hacker, if
> > > my linux system has the correct settings ?
> > 
> > Use the vendor supplied kernels ?
> 
> Yes, I am using them.
> Now back to my question, how do I found out if option X is set or not ?

Check the vendor supplied source package ?

Re: How to check the kernel compile options ?

[David Balazic]

Alan Cox wrote:
> 
> > > > How can I figure out in 5 minutes, without a kernel hacker, if
> > > > my linux system has the correct settings ?
> > >
> > > Use the vendor supplied kernels ?
> >
> > Yes, I am using them.
> > Now back to my question, how do I found out if option X is set or not ?
> 
> Check the vendor supplied source package ?

Part of the question was "in 5 minutes". Finding the install CD,
installing the source package, "checking" it... are more than 5 minutes.
Compared to checking out the kernel parameters on HP-UX, for example.

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How to check the kernel compile options ?

[Allan Sandfeld]

On Monday 04 February 2002 18:12, David Balazic wrote:
> Alan Cox wrote:
> > > > > How can I figure out in 5 minutes, without a kernel hacker, if
> > > > > my linux system has the correct settings ?
> > > >
> > > > Use the vendor supplied kernels ?
> > >
> > > Yes, I am using them.
> > > Now back to my question, how do I found out if option X is set or not ?
> >
> > Check the vendor supplied source package ?
>
> Part of the question was "in 5 minutes". Finding the install CD,
> installing the source package, "checking" it... are more than 5 minutes.
> Compared to checking out the kernel parameters on HP-UX, for example.

What he is saying is that you can't do that, generically. Some options are 
available at runtime through /proc, but most are not. You need to check what 
happend back at compile time.

-Allan

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 4, 2002 06:16 pm, Allan Sandfeld wrote:
> On Monday 04 February 2002 18:12, David Balazic wrote:
> > Alan Cox wrote:
> > > > > > How can I figure out in 5 minutes, without a kernel hacker, if
> > > > > > my linux system has the correct settings ?
> > > > >
> > > > > Use the vendor supplied kernels ?
> > > >
> > > > Yes, I am using them.
> > > > Now back to my question, how do I found out if option X is set or not ?
> > >
> > > Check the vendor supplied source package ?
> >
> > Part of the question was "in 5 minutes". Finding the install CD,
> > installing the source package, "checking" it... are more than 5 minutes.
> > Compared to checking out the kernel parameters on HP-UX, for example.
> 
> What he is saying is that you can't do that, generically. Some options are 
> available at runtime through /proc, but most are not. You need to check what 
> happend back at compile time.

Right, there is a religious issue here: some core kernel hackers believe
that it is wrong to encode kernel configuration in the kernel, and that
is why it's not available.  Technically it is not difficult, nor is it
difficult to make it memory-efficient.

-- 
Daniel

Re: How to check the kernel compile options ?

[Arjan van de Ven]

> > What he is saying is that you can't do that, generically. Some options are
> > available at runtime through /proc, but most are not. You need to check what
> > happend back at compile time.
> 
> Right, there is a religious issue here: some core kernel hackers believe
> that it is wrong to encode kernel configuration in the kernel, and that
> is why it's not available.  Technically it is not difficult, nor is it
> difficult to make it memory-efficient.

It's silly to put it permanently in unswappable memory; putting it in 
/lib/modules/`uname -r/
somewhere does make tons of sense instead.

Re: How to check the kernel compile options ?

[Ben Greear]

Arjan van de Ven wrote:

>>>What he is saying is that you can't do that, generically. Some options are
>>>available at runtime through /proc, but most are not. You need to check what
>>>happend back at compile time.
>>>
>>Right, there is a religious issue here: some core kernel hackers believe
>>that it is wrong to encode kernel configuration in the kernel, and that
>>is why it's not available.  Technically it is not difficult, nor is it
>>difficult to make it memory-efficient.
>>
> 
> It's silly to put it permanently in unswappable memory; putting it in 
> /lib/modules/`uname -r/
> somewhere does make tons of sense instead.


That is not guaranteed to be correct though.  Why not allow the
builder of the kernel to choose an option to keep it in the
kernel unswappable memory, or to place it in the lib/modules
directory?  That should allow the builder to choose tho option that
is best for them, with no adverse impacts on those who choose
a different option...



-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 4, 2002 07:14 pm, Arjan van de Ven wrote:
> > > What he is saying is that you can't do that, generically. Some options are
> > > available at runtime through /proc, but most are not. You need to check what
> > > happend back at compile time.
> > 
> > Right, there is a religious issue here: some core kernel hackers believe
> > that it is wrong to encode kernel configuration in the kernel, and that
> > is why it's not available.  Technically it is not difficult, nor is it
> > difficult to make it memory-efficient.
> 
> It's silly to put it permanently in unswappable memory; putting it in 
> /lib/modules/`uname -r/
> somewhere does make tons of sense instead.

Could you show me where I suggested putting it "permanently in unswappable memory"?

-- 
Daniel

Re: How to check the kernel compile options ?

[H. Peter Anvin]

Followup to:  <E16Xnn7-0004mp-00@starship.berlin>
By author:    Daniel Phillips <phillips@bonn-fries.net>
In newsgroup: linux.dev.kernel
> > 
> > It's silly to put it permanently in unswappable memory; putting it in 
> > /lib/modules/`uname -r/
> > somewhere does make tons of sense instead.
> 
> Could you show me where I suggested putting it "permanently in unswappable memory"?
> 

You suggested putting it in the kernel, which is permanently in
unswappable memory.  Using a module is, as I pointed out earlier,
worse than useless.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 4, 2002 11:11 pm, H. Peter Anvin wrote:
> By author:    Daniel Phillips <phillips@bonn-fries.net>
> > Somebody said:
> > > It's silly to put it permanently in unswappable memory; putting it in 
> > > /lib/modules/`uname -r/ somewhere does make tons of sense instead.
> > 
> > Could you show me where I suggested putting it "permanently in unswappable memory"?
> 
> You suggested putting it in the kernel, which is permanently in
> unswappable memory.  Using a module is, as I pointed out earlier,
> worse than useless.

Is this what you you're referring to:

On February 4, 2002 07:22 pm, H. Peter Anvin wrote:
> Uhm, no.  The problem with it is that you're using kernel memory
> because you're not willing to manage userspace competently, so modules
> (in fact, *using modules at all*) would be right out.

I don't see your point.

/me points to where he said 'religious issue' above.

-- 
Daniel

Re: How to check the kernel compile options ?

[J.A. Magallon]

On 20020204 Arjan van de Ven wrote:
>
>> > What he is saying is that you can't do that, generically. Some options are
>> > available at runtime through /proc, but most are not. You need to check what
>> > happend back at compile time.
>> 
>> Right, there is a religious issue here: some core kernel hackers believe
>> that it is wrong to encode kernel configuration in the kernel, and that
>> is why it's not available.  Technically it is not difficult, nor is it
>> difficult to make it memory-efficient.
>
>It's silly to put it permanently in unswappable memory; putting it in 
>/lib/modules/`uname -r/
>somewhere does make tons of sense instead.

Mandrake (and think also redhat) save the kenel config used at
/boot/config-x.y.z-abc

So look for /boot/config-`uname -r`

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre7-slb #1 SMP Mon Feb 4 21:21:52 CET 2002 i686

Re: How to check the kernel compile options ?

[Samuli Suonpaa]

David Balazic <david.balazic@uni-mb.si> writes:
> Alan Cox wrote:
>> Use the vendor supplied kernels ?
> Yes, I am using them.
> Now back to my question, how do I found out if option X is set or not ?

It depends on the vendor. All Debian kernel-packages have kernel's
config-file in /boot. Which is nice.

Suonpää...

Re: How to check the kernel compile options ?

[Thomas Capricelli]

A really useful patch makes all the options appeared in /proc/config.gz. It's 
used by SuSE kernels among others (mine, too :)
You can find the patch on kernelnewbies.org (don't remember where exactly)


zgrep CONFIG_PROC /proc/config.gz
	will give you the answer.

I have absolutely no clue why such a useful things is not integrated into the 
kernel yet. It's even useful for such things as "build a kernel using the 
same options as I have on current kernel but I don't know where my .config 
is".

FWICS It seems harmful to me.


Thomas

On Monday 04 February 2002 17:01, David Balazic wrote:
> Hi!
>
> This problem again :-)
>
> I purchase/download a program for linux.
> It says it requires certain kernel features, for example :
> CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET
>
> How can I figure out in 5 minutes, without a kernel hacker, if
> my linux system has the correct settings ?
>
> This is a real life question, probably more suitable to ask
> on some distributions mail list, but I thought I'll start here.
>
> TIA,
> david
>
> P.S.: Please CC me on the answers.

Re: How to check the kernel compile options ?

[David Relson]

At 12:34 PM 2/4/02, you wrote:


>A really useful patch makes all the options appeared in /proc/config.gz. It's
>used by SuSE kernels among others (mine, too :)
>You can find the patch on kernelnewbies.org (don't remember where exactly)
>
>
>zgrep CONFIG_PROC /proc/config.gz
>         will give you the answer.
>
>I have absolutely no clue why such a useful things is not integrated into the
>kernel yet. It's even useful for such things as "build a kernel using the
>same options as I have on current kernel but I don't know where my .config
>is".
>
>FWICS It seems harmful to me.
>
>
>Thomas


I remember discussion of that patch some time ago and the main complaint 
about it was that it increases the size of the kernel, i.e. vmlinuz.  Why 
not put the need info in a module?  Doing that would enable the following 
command:

         zgrep CONFIG_PROC /lib/modules/`uname -r`/config.gz

(or something similar).

David

Re: How to check the kernel compile options ?

[H. Peter Anvin]

Followup to:  <4.3.2.7.2.20020204124812.00aec590@mail.osagesoftware.com>
By author:    David Relson <relson@osagesoftware.com>
In newsgroup: linux.dev.kernel
> 
> I remember discussion of that patch some time ago and the main complaint 
> about it was that it increases the size of the kernel, i.e. vmlinuz.  Why 
> not put the need info in a module?  Doing that would enable the following 
> command:
> 
>          zgrep CONFIG_PROC /lib/modules/`uname -r`/config.gz
> 
> (or something similar).
> 

Uhm, no.  The problem with it is that you're using kernel memory
because you're not willing to manage userspace competently, so modules
(in fact, *using modules at all*) would be right out.

I have had in my /sbin/installkernel a clause to save .config as
config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
that[1] is, quite frankly, a moron.

	-hpa

[1] or rather, not doing it without knowing exactly why they aren't --
sometimes there are good reasons for doing so.
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: How to check the kernel compile options ?

[Alex Bligh - linux-kernel]

--On Monday, 04 February, 2002 10:22 AM -0800 "H. Peter Anvin" 
<hpa@zytor.com> wrote:

> I have had in my /sbin/installkernel a clause to save .config as
> config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
> that[1] is, quite frankly, a moron.

Always being willing to rise to the challenge of being called
a moron:

Seems to me that if the prefered method of booting becomes
an initrd-esque thing + pivot_root, I /may/ (reasonably)
perhaps have these files on the initrd anyway, and /might/
not have it mounted (or at least not mounted on the same
path across multiple distributions), in which case being
able to access them through /proc (which incidentally
could do the decompression for us, giving plain text
out of /proc and using minimal memory) might be useful.
[of course this /is/ saving config-foo, but to a place
where it's might be useful to access it from /proc]

Ditto ksyms etc.

An advantage of having the kernel, config, ksyms
etc. as one atomic lump is one of the same reasons
as people are looking to have kernel and modules as one
atomic lump - i.e. much less chance of the wrong
ones being looked at.

I would be surprised if there is anyone on this list
who has not lost at some point either the .config, the
kysms, or something similar associated with at least
one build they've made.

--
Alex Bligh

Re: How to check the kernel compile options ?

[H. Peter Anvin]

Alex Bligh - linux-kernel wrote:

> 
> I would be surprised if there is anyone on this list
> who has not lost at some point either the .config, the
> kysms, or something similar associated with at least
> one build they've made.
> 


Sure.  And people have lost their root filesystems due to "rm -rf /".
That doesn't mean we build the entire (real) root filesystem into the kernel.

	-hpa

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 5, 2002 11:13 pm, H. Peter Anvin wrote:
> Alex Bligh - linux-kernel wrote:
> 
> > 
> > I would be surprised if there is anyone on this list
> > who has not lost at some point either the .config, the
> > kysms, or something similar associated with at least
> > one build they've made.
> > 
> 
> 
> Sure.  And people have lost their root filesystems due to "rm -rf /".
> That doesn't mean we build the entire (real) root filesystem into the kernel.

Well, it seems to be down to you and Arjan aguing that this usability
improvement isn't needed, vs quite a few *users* who are complaining about
the current state of things, as well they should because it's less good than
it could be.

-- 
Daniel

Re: How to check the kernel compile options ?

[Mike Touloumtzis]

On Wed, Feb 06, 2002 at 10:15:49AM +0100, Daniel Phillips wrote:
> On February 5, 2002 11:13 pm, H. Peter Anvin wrote:
> > Alex Bligh - linux-kernel wrote:
> > 
> > > I would be surprised if there is anyone on this list
> > > who has not lost at some point either the .config, the
> > > kysms, or something similar associated with at least
> > > one build they've made.
> > 
> > Sure.  And people have lost their root filesystems due to "rm -rf /".
> > That doesn't mean we build the entire (real) root filesystem into the
> > kernel.
> 
> Well, it seems to be down to you and Arjan aguing that this usability
> improvement isn't needed, vs quite a few *users* who are complaining about
> the current state of things, as well they should because it's less good than
> it could be.

Numeric participation on lkml discussions is not an indication of much.
If lkml accurately reflected the state of Linux and its userbase, Linux
would be the most crash-prone, bug-ridden, chaotic environment ever :-).

There's probably a lot of people (like me) who use distribution tools like
Debian's kernel-package to build and manage kernel packages.  If you're
used to using the right packaging tools, it looks kind of silly to stuff
text files into the kernel in case they're deleted, instead of doing:

$ dpkg -x kernel-image-2.4.17_1.00.Custom_i386.deb ~/tmp/
$ cat ~/tmp/boot/config-2.4.17

The kernel is just a program, and this is a tools problem.  You don't
see people arguing that cat's documentation should be moved into /bin/cat
in case administrators misplace "cat.1.gz".

miket

Re: How to check the kernel compile options ?

[Marco Colombo]

On Wed, 6 Feb 2002, Mike Touloumtzis wrote:

[...]

> The kernel is just a program, and this is a tools problem.  You don't
> see people arguing that cat's documentation should be moved into /bin/cat
> in case administrators misplace "cat.1.gz".

FSF. Compare cat --help on Linux and on Solaris... B-)

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 05:13 am, Mike Touloumtzis wrote:
> On Wed, Feb 06, 2002 at 10:15:49AM +0100, Daniel Phillips wrote:
> > On February 5, 2002 11:13 pm, H. Peter Anvin wrote:
> > > Alex Bligh - linux-kernel wrote:
> > > 
> > > > I would be surprised if there is anyone on this list
> > > > who has not lost at some point either the .config, the
> > > > kysms, or something similar associated with at least
> > > > one build they've made.
> > > 
> > > Sure.  And people have lost their root filesystems due to "rm -rf /".
> > > That doesn't mean we build the entire (real) root filesystem into the
> > > kernel.
> > 
> > Well, it seems to be down to you and Arjan aguing that this usability
> > improvement isn't needed, vs quite a few *users* who are complaining about
> > the current state of things, as well they should because it's less good 
than
> > it could be.
> 
> Numeric participation on lkml discussions is not an indication of much.
> If lkml accurately reflected the state of Linux and its userbase, Linux
> would be the most crash-prone, bug-ridden, chaotic environment ever :-).
> 
> There's probably a lot of people (like me) who use distribution tools like
> Debian's kernel-package to build and manage kernel packages.  If you're
> used to using the right packaging tools, it looks kind of silly to stuff
> text files into the kernel in case they're deleted, instead of doing:
> 
> $ dpkg -x kernel-image-2.4.17_1.00.Custom_i386.deb ~/tmp/
> $ cat ~/tmp/boot/config-2.4.17
> 
> The kernel is just a program, and this is a tools problem.  You don't
> see people arguing that cat's documentation should be moved into /bin/cat
> in case administrators misplace "cat.1.gz".

Cat is standard, kernels aren't.  When was the last time you installed a
custom cat?

-- 
Daniel

Re: How to check the kernel compile options ?

[Mike Touloumtzis]

On Thu, Feb 07, 2002 at 02:18:20PM +0100, Daniel Phillips wrote:
> On February 7, 2002 05:13 am, Mike Touloumtzis wrote:
> > 
> > The kernel is just a program, and this is a tools problem.  You don't
> > see people arguing that cat's documentation should be moved into /bin/cat
> > in case administrators misplace "cat.1.gz".
> 
> Cat is standard, kernels aren't.  When was the last time you installed a
> custom cat?

I installed a custom rsync just the other day, and I did it by downloading
the Debian rsync source, patching it, and building a Debian package.
I would certainly do the same for cat if I needed to.

Sorry, I still don't see any fundamental difference.

miket

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 07:26 pm, Mike Touloumtzis wrote:
> On Thu, Feb 07, 2002 at 02:18:20PM +0100, Daniel Phillips wrote:
> > On February 7, 2002 05:13 am, Mike Touloumtzis wrote:
> > > 
> > > The kernel is just a program, and this is a tools problem.  You don't
> > > see people arguing that cat's documentation should be moved into /bin/cat
> > > in case administrators misplace "cat.1.gz".
> > 
> > Cat is standard, kernels aren't.  When was the last time you installed a
> > custom cat?
> 
> I installed a custom rsync just the other day, and I did it by downloading
> the Debian rsync source, patching it, and building a Debian package.
> I would certainly do the same for cat if I needed to.
> 
> Sorry, I still don't see any fundamental difference.

Yes, and would you configure cat?  Which options would you select?

I'm trying to avoid just saying 'you're being silly', but it's what I really
mean.

-- 
Daniel

Re: How to check the kernel compile options ?

[Mike Touloumtzis]

On Thu, Feb 07, 2002 at 08:19:36PM +0100, Daniel Phillips wrote:
> On February 7, 2002 07:26 pm, Mike Touloumtzis wrote:
> > 
> > I installed a custom rsync just the other day, and I did it by downloading
> > the Debian rsync source, patching it, and building a Debian package.
> > I would certainly do the same for cat if I needed to.
> > 
> > Sorry, I still don't see any fundamental difference.
> 
> Yes, and would you configure cat?  Which options would you select?
> 
> I'm trying to avoid just saying 'you're being silly', but it's what I
> really mean.

I'm talking about rsync now, not cat (that was reductio ad absurdum to
make a point).  In case you haven't compiled any userspace programs in
a while: many of them have configuration options.  In the case of rsync,
things like "--enable-profile" and "--disable-ipv6".

I fail to see how tracking a custom compiled rsync is any different
from tracking a custom compiled kernel.  In both cases you have local
history to track and a group of files to bundle together.

Let's replay this discussion as I see it:

You: Users are clamoring for the inclusion of configuration information
     in the kernel.  They clearly need it, so let's include it even
     though it has no functional purpose.

Me: Actually, I'm a user and the distribution-provided packaging tools
    work fine for this purpose.  We don't bundle similar information
    into the binaries of userspace tools.

You: Userspace tools don't have configuration options like the kernel.

Me: Yes they do.

Arguing that people don't custom configure anything but the kernel is
a dead end.  Also, I have already claimed that I don't need any of the
"stuffing config info into kernels" solutions mentioned on this thread,
so it's hard to try to convince me I need this feature.

Some possible available avenues of argument for you are:

-- "You don't know what you're missing".

   You can argue that moving configuration info into the kernel is
   fundamentally better than, or makes things easier than, bundling
   it into a package.  This is a hard sell, since in an earlier mail
   I demonstrated that I can get at the configuration info in a kernel
   package with two commands.

-- "You are not a typical user".

   Since I'm satisfied with the status quo, your best defense of this
   change is to argue that I am not the target audience for this change.

   As far as I can tell, the userbase of Linux, includes, in descending
   order of frequency:

   1) People who use prepackaged distribution kernels.
   2) People who build their own kernels based on distribution packaging
      systems, or have evolved their own systems of kernel management
      over the years.
   3) People who sling kernels around like loose change and forget where
      each kernel came from.

   AFAICT most of the "config info needs to go in the kernel" arguments
   seem to come from camp #3.  I think those people should just get
   their acts together or start using the right tools instead.

   When I first started using Unix (on a multiuser system, back in
   school), I was struck by how messy it was.  The root directories
   contained all kinds of locally added directories and forgotten crap.
   The systems were a mishmash of forgotten compiled-from-source packages,
   temporary workarounds, expedient measures, and haphazardly patcheded
   kernels.

   The extent to which the distributors and other measures like the FHS
   have rationalized this situation, and automated the tasks it sprung
   from, continues to amaze me.  My sneaking suspicion is that people
   who want to stuff configuration info into the kernel haven't made that
   leap yet.  That's why I'm being a bit of a harsh critic of the concept
   (plus, it seems to be par for the course on lkml :-).

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.

miket

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 09:34 pm, Mike Touloumtzis wrote:
> Some possible available avenues of argument for you are:

I think you're just arguing for the sake of argument, which basically sums
up all the arguments we've seen against this.

Let me put it in simple terms: you've got an alarm clock, haven't you?  When 
you set the alarm, you don't need to have any little light on the front that 
tells you the alarm is set, do you?  Because, after all you're not stupid, 
you know you set it.  And you can always get out of bed and look at the 
position of the switch, right?

(I hope I just demonstrated the difference between reducto ad absurdum and 
'just plain silly'.)

-- 
Daniel

Re: How to check the kernel compile options ?

[Mike Touloumtzis]

On Thu, Feb 07, 2002 at 09:54:30PM +0100, Daniel Phillips wrote:
> On February 7, 2002 09:34 pm, Mike Touloumtzis wrote:
> > Some possible available avenues of argument for you are:
> 
> I think you're just arguing for the sake of argument, which basically sums
> up all the arguments we've seen against this.

Not at all.  I really believe that embedded unnecessary information in
the kernel is a bad idea.  I don't want my kernels to get any bigger
than they are now unless useful features are being added (I have no
problem with that).  I develop for embedded devices, so I'm particularly
sensitive to this issue.

My understanding is that "keep features out of the kernel if possible"
is the majority opinion, not a crackpot weirdo stance.

> Let me put it in simple terms: you've got an alarm clock, haven't you?  When 
> you set the alarm, you don't need to have any little light on the front that 
> tells you the alarm is set, do you?  Because, after all you're not stupid, 
> you know you set it.  And you can always get out of bed and look at the 
> position of the switch, right?

I don't think this is a close enough analogy to illustrate anything.
The examples I chose to illustrate my points were IMHO closely related
software packaging issues.

miket

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 10:08 pm, Mike Touloumtzis wrote:
> On Thu, Feb 07, 2002 at 09:54:30PM +0100, Daniel Phillips wrote:
> > On February 7, 2002 09:34 pm, Mike Touloumtzis wrote:
> > > Some possible available avenues of argument for you are:
> > 
> > I think you're just arguing for the sake of argument, which basically sums
> > up all the arguments we've seen against this.
> 
> Not at all.  I really believe that embedded unnecessary information in
> the kernel is a bad idea.  I don't want my kernels to get any bigger
> than they are now unless useful features are being added (I have no
> problem with that).  I develop for embedded devices, so I'm particularly
> sensitive to this issue.

I've heard that one before, from people who should know better.  That's what 
config options are for, or it's certainly a major reason for having config 
options.  Heck, I'd be satisfied if it was off by default.  I'd *always* turn 
it on, personally.

> My understanding is that "keep features out of the kernel if possible"
> is the majority opinion, not a crackpot weirdo stance.

Right, but would you buy a car without upholstery on the seats?  Wait, maybe 
you would.

> > Let me put it in simple terms: you've got an alarm clock, haven't you?  
> > When you set the alarm, you don't need to have any little light on the 
> > front that tells you the alarm is set, do you?  Because, after all you're 
> > not stupid, you know you set it.  And you can always get out of bed and 
> > look at the position of the switch, right?
> 
> I don't think this is a close enough analogy to illustrate anything.

Right, it's tough to explain usability to someone who has no clue what that 
is.

OK, I'm out, I've made my point, you are welcome to attempt to demolish it 
without fear of retaliation.

-- 
Daniel

Re: How to check the kernel compile options ?

[John Alvord]

On Thu, 7 Feb 2002 13:08:23 -0800, Mike Touloumtzis
<miket@bluemug.com> wrote:

>On Thu, Feb 07, 2002 at 09:54:30PM +0100, Daniel Phillips wrote:
>> On February 7, 2002 09:34 pm, Mike Touloumtzis wrote:
>> > Some possible available avenues of argument for you are:
>> 
>> I think you're just arguing for the sake of argument, which basically sums
>> up all the arguments we've seen against this.
>
>Not at all.  I really believe that embedded unnecessary information in
>the kernel is a bad idea.  I don't want my kernels to get any bigger
>than they are now unless useful features are being added (I have no
>problem with that).  I develop for embedded devices, so I'm particularly
>sensitive to this issue.
>
>My understanding is that "keep features out of the kernel if possible"
>is the majority opinion, not a crackpot weirdo stance.
>
>> Let me put it in simple terms: you've got an alarm clock, haven't you?  When 
>> you set the alarm, you don't need to have any little light on the front that 
>> tells you the alarm is set, do you?  Because, after all you're not stupid, 
>> you know you set it.  And you can always get out of bed and look at the 
>> position of the switch, right?
>
>I don't think this is a close enough analogy to illustrate anything.
>The examples I chose to illustrate my points were IMHO closely related
>software packaging issues.

An often heard argument is "can it be done in user space", which seems
very applicable here.

john alvord

Re: How to check the kernel compile options ?

[Alex Bligh - linux-kernel]

--On Thursday, 07 February, 2002 1:08 PM -0800 Mike Touloumtzis 
<miket@bluemug.com> wrote:

> My understanding is that "keep features out of the kernel if possible"
> is the majority opinion, not a crackpot weirdo stance.

Mmmm... well my understanding is that the majority opinion is not
to minimize kernel functionality as a goal in isolation, but to
minimize putting into the kernel features which are done just
as well in userspace. Note the words 'just as well'. Consider,
for instance, the recent discussion (like it or not) on packing
some initrd equivalent with modules for all drivers, as opposed
to keeping said modules in separate files on traditional disk
storage. I cite this as it's about the closest analogy.

The argument comes down to 'do you want the option of dealing
with your kernel as one lump, or multiple smaller lumps' (i.e.
kernel as we know it, modules, ksysms, config file, tea cosy,
jacuzzi etc. - remember I suggested one be able to stick
any files there). It seems sensible at a distribution level to
restrict the use of this option (you could put the whole of
/bin there if you wanted). It seems perverse to reject the
concept of the option in toto, given that it's, urm, an option.
Just like any option, it is possible, though far from compulsorary,
to mindlessly abuse it.

--
Alex Bligh

Re: How to check the kernel compile options ?

[Daniel Phillips]

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.

-- 
Daniel

Re: How to check the kernel compile options ?

[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

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
> 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.

The cost is *zero* if you don't enable the option, is this concept difficult
for you?

-- 
Daniel

Re: How to check the kernel compile options ?

[Mike Touloumtzis]

On Thu, Feb 07, 2002 at 11:09:09PM +0100, Daniel Phillips wrote:
> On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
> > 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.
> 
> The cost is *zero* if you don't enable the option, is this concept difficult
> for you?

That argument can be used to justify almost anything.  But it's not
zero maintenance cost or code complexity cost.  No one wants the kernel
to be an unmaintainable nest of CONFIG_FOO and #ifdef BAR because of
"zero cost" options.

miket

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 7, 2002 11:13 pm, Mike Touloumtzis wrote:
> On Thu, Feb 07, 2002 at 11:09:09PM +0100, Daniel Phillips wrote:
> > On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
> > > 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.
> > 
> > The cost is *zero* if you don't enable the option, is this concept difficult
> > for you?
> 
> That argument can be used to justify almost anything.  But it's not
> zero maintenance cost or code complexity cost.  No one wants the kernel
> to be an unmaintainable nest of CONFIG_FOO and #ifdef BAR because of
> "zero cost" options.

OK, there we are, your real argument: you think adding this option will make
the kernel unmaintainable.

feh.

-- 
Daniel

Re: How to check the kernel compile options ?

[Horst von Brand]

Daniel Phillips <phillips@bonn-fries.net> said:
> On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
> > 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.
> 
> The cost is *zero* if you don't enable the option, is this concept difficult
> for you?

It isn't zero: Somebody has to add the support, check/fix interactions with
other features, write documentation, keep the support and its documentation
up to date when stuff in the kernel changes, userland (and user) has to be
prepared (and checked that it works if the feature is present, and find
workarounds if it isn't), ...

It might be a small cost, but N * small gets big _very_ fast, and the value
is marginal at best in this case. There are many other such "small cost
features" with equally small value results that haven't been included. One
of the big reasons why I like Linux, BTW.
-- 
Horst von Brand http://counter.li.org # 22616

Re: How to check the kernel compile options ?

[Daniel Phillips]

On February 8, 2002 09:53 pm, Horst von Brand wrote:
> Daniel Phillips <phillips@bonn-fries.net> said:
> > On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
> > > 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.
> > 
> > The cost is *zero* if you don't enable the option, is this concept difficult
> > for you?
> 
> It isn't zero: Somebody has to add the support, check/fix interactions with
> other features, write documentation, keep the support and its documentation
> up to date when stuff in the kernel changes, userland (and user) has to be
> prepared (and checked that it works if the feature is present, and find
> workarounds if it isn't), ...
>
> It might be a small cost, but N * small gets big _very_ fast, and the value
> is marginal at best in this case. There are many other such "small cost
> features" with equally small value results that haven't been included. One
> of the big reasons why I like Linux, BTW.

Non sequitur.  You are talking about a completely different cost than he was.

But I'll bite: if a volunteer wishes to contribute the needed work, and the
feature impacts no systems outside itself, then you have no argument.

-- 
Daniel

Re: How to check the kernel compile options ?

[Randy.Dunlap]

On Fri, 8 Feb 2002, Horst von Brand wrote:

| Daniel Phillips <phillips@bonn-fries.net> said:
| > On February 7, 2002 10:41 pm, Mike Touloumtzis wrote:
| > > 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.
| >
| > The cost is *zero* if you don't enable the option, is this concept difficult
| > for you?
|
| It isn't zero: Somebody has to add the support, check/fix interactions with
| other features, write documentation, keep the support and its documentation
| up to date when stuff in the kernel changes, userland (and user) has to be
| prepared (and checked that it works if the feature is present, and find
| workarounds if it isn't), ...

There are customers who actually require a decent, reasonable
solution to this problem.  If there is a decent, reasonable
solution, great.  If not, then one will be generated.

| It might be a small cost, but N * small gets big _very_ fast, and the value
| is marginal at best in this case. There are many other such "small cost
| features" with equally small value results that haven't been included. One
| of the big reasons why I like Linux, BTW.

-- 
~Randy

Re: How to check the kernel compile options ?

[Alex Bligh - linux-kernel]

--On Thursday, 07 February, 2002 12:34 PM -0800 Mike Touloumtzis 
<miket@bluemug.com> wrote:

> I'm talking about rsync now, not cat (that was reductio ad absurdum to
> make a point).  In case you haven't compiled any userspace programs in
> a while: many of them have configuration options.  In the case of rsync,
> things like "--enable-profile" and "--disable-ipv6".

Well, picking a package with a non-trivial config file for compilation,
and picking the one which is most easy to recompile (postfix):

shed:/home/amb# postconf | head
2bounce_notice_recipient = postmaster
access_map_reject_code = 554
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_mail_to_commands = alias,forward
...
command_directory = /usr/sbin
...


I'd say that's storing it's compilation config (it's in there too)
live - at least sufficient to allow me to rebuild it. And I've used
it.

> A final argument for using packaging/bundling tools and userspace files
> instead of files in /proc for tracking kernel metadata:

Noone is suggesting that it be compulsorary to delete your 'userspace'
(read 'conventional file system') version of .config etc. The argument
is merely that it is worth the few thousand bytes (one page) of
swapoutable stuff kept with the kernel as well to aid debugging,
rebuilding, etc.; for instance, if you've ever done a binary chop
for 'which config livelocks my kernel on load', this means
typing cp/mv rather fewer times. If you've ever misplaced/mismatched
your .config/kysms, whatever, this will help immeasurably. If you
are booting in an environment where it's easier to move a single
file about (think tftp boot in a network environment for example),
you get the config on there for free. Each of these I have used.

--
Alex Bligh

Re: How to check the kernel compile options ?

[Bill Davidsen]

On Tue, 5 Feb 2002, Alex Bligh - linux-kernel wrote:

  May I suggest that you have you favorite install script put a copy in
/boot instead? I also hacked my startup to Slink in boot to the current
modules directory, SystemMap and boot kernel.

> I would be surprised if there is anyone on this list
> who has not lost at some point either the .config, the
> kysms, or something similar associated with at least
> one build they've made.

  Or forgotten to make oldconfig, or lots of other things. But that
doesn't make a good argument for putting the config permanently in /proc
instead of saving it if you want it, does it? If you could remember to
make the module with the config, you could remember to save it. Or even
have modules_install save the info in a file in the modules directory,
that would get the info without locking it in memory.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: How to check the kernel compile options ?

[David Relson]

At 01:22 PM 2/4/02, you wrote:
>Followup to:  <4.3.2.7.2.20020204124812.00aec590@mail.osagesoftware.com>
>By author:    David Relson <relson@osagesoftware.com>
>In newsgroup: linux.dev.kernel
> >
> > I remember discussion of that patch some time ago and the main complaint
> > about it was that it increases the size of the kernel, i.e. vmlinuz.  Why
> > not put the need info in a module?  Doing that would enable the following
> > command:
> >
> >          zgrep CONFIG_PROC /lib/modules/`uname -r`/config.gz
> >
> > (or something similar).
> >
>
>Uhm, no.  The problem with it is that you're using kernel memory
>because you're not willing to manage userspace competently, so modules
>(in fact, *using modules at all*) would be right out.

Yeah, it does have the undesirable dependency on modules, doesn't it?


>I have had in my /sbin/installkernel a clause to save .config as
>config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
>that[1] is, quite frankly, a moron.

Why not a simple patch for "make install" to do this?

Re: How to check the kernel compile options ?

[Keith Owens]

On Mon, 04 Feb 2002 13:34:40 -0500, 
David Relson <relson@osagesoftware.com> wrote:
>At 01:22 PM 2/4/02, you wrote:
>>I have had in my /sbin/installkernel a clause to save .config as
>>config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
>>that[1] is, quite frankly, a moron.
>
>Why not a simple patch for "make install" to do this?

Simple?  From kbuild 2.5 which does exactly this ...

mainmenu_name "ix86 Installation"

choice 'Format to compile kernel in' \
	"vmlinux	CONFIG_VMLINUX \
	 vmlinuz	CONFIG_VMLINUZ \
	 bzImage	CONFIG_BZIMAGE \
	 zImage		CONFIG_ZIMAGE" bzImage

bool 'Use a prefix on install paths' CONFIG_INSTALL_PREFIX
if [ "$CONFIG_INSTALL_PREFIX" = "y" ]; then
  string '  Prefix for install paths' CONFIG_INSTALL_PREFIX_NAME ""
fi
string 'Where to install the kernel' CONFIG_INSTALL_KERNEL_NAME "/lib/modules/KERNELRELEASE/KERNELBASENAME"
bool 'Install System.map' CONFIG_INSTALL_SYSTEM_MAP
if [ "$CONFIG_INSTALL_SYSTEM_MAP" = "y" ]; then
  string '  Where to install System.map' CONFIG_INSTALL_SYSTEM_MAP_NAME "/lib/modules/KERNELRELEASE/System.map"
fi
bool 'Install .config' CONFIG_INSTALL_CONFIG
if [ "$CONFIG_INSTALL_CONFIG" = "y" ]; then
  string '  Where to install .config' CONFIG_INSTALL_CONFIG_NAME "/lib/modules/KERNELRELEASE/.config"
fi
if [ "$CONFIG_VMLINUX" != "y" ]; then
  bool '  Install vmlinux for debugging' CONFIG_INSTALL_VMLINUX
  if [ "$CONFIG_INSTALL_VMLINUX" = "y" ]; then
    string '    Where to install vmlinux' CONFIG_INSTALL_VMLINUX_NAME "/lib/modules/KERNELRELEASE/vmlinux"
  fi
fi
bool 'Run a post-install script or command' CONFIG_INSTALL_SCRIPT
if [ "$CONFIG_INSTALL_SCRIPT" = "y" ]; then
  string '  Post-install script or command name' CONFIG_INSTALL_SCRIPT_NAME ""
fi

Re: How to check the kernel compile options ?

[Thomas Capricelli]

I like this. Which bring me to the latest FAQ : when will that be integrated? 

Has linus ever stated why kbuil/cml2 haven't been integrated yet ? They're 
almost orthogonal to the IO changes. And, anyway, the compilation of 2.5.x 
seems _already_ broken.

Thomas


On Monday 04 February 2002 22:09, Keith Owens wrote:
> On Mon, 04 Feb 2002 13:34:40 -0500,
>
> David Relson <relson@osagesoftware.com> wrote:
> >At 01:22 PM 2/4/02, you wrote:
> >>I have had in my /sbin/installkernel a clause to save .config as
> >>config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
> >>that[1] is, quite frankly, a moron.
> >
> >Why not a simple patch for "make install" to do this?
>
> Simple?  From kbuild 2.5 which does exactly this ...
>
> mainmenu_name "ix86 Installation"
>
> choice 'Format to compile kernel in' \
> 	"vmlinux	CONFIG_VMLINUX \
> 	 vmlinuz	CONFIG_VMLINUZ \
> 	 bzImage	CONFIG_BZIMAGE \
> 	 zImage		CONFIG_ZIMAGE" bzImage
>
> bool 'Use a prefix on install paths' CONFIG_INSTALL_PREFIX
> if [ "$CONFIG_INSTALL_PREFIX" = "y" ]; then
>   string '  Prefix for install paths' CONFIG_INSTALL_PREFIX_NAME ""
> fi
> string 'Where to install the kernel' CONFIG_INSTALL_KERNEL_NAME
> "/lib/modules/KERNELRELEASE/KERNELBASENAME" bool 'Install System.map'
> CONFIG_INSTALL_SYSTEM_MAP
> if [ "$CONFIG_INSTALL_SYSTEM_MAP" = "y" ]; then
>   string '  Where to install System.map' CONFIG_INSTALL_SYSTEM_MAP_NAME
> "/lib/modules/KERNELRELEASE/System.map" fi
> bool 'Install .config' CONFIG_INSTALL_CONFIG
> if [ "$CONFIG_INSTALL_CONFIG" = "y" ]; then
>   string '  Where to install .config' CONFIG_INSTALL_CONFIG_NAME
> "/lib/modules/KERNELRELEASE/.config" fi
> if [ "$CONFIG_VMLINUX" != "y" ]; then
>   bool '  Install vmlinux for debugging' CONFIG_INSTALL_VMLINUX
>   if [ "$CONFIG_INSTALL_VMLINUX" = "y" ]; then
>     string '    Where to install vmlinux' CONFIG_INSTALL_VMLINUX_NAME
> "/lib/modules/KERNELRELEASE/vmlinux" fi
> fi
> bool 'Run a post-install script or command' CONFIG_INSTALL_SCRIPT
> if [ "$CONFIG_INSTALL_SCRIPT" = "y" ]; then
>   string '  Post-install script or command name' CONFIG_INSTALL_SCRIPT_NAME
> "" fi
>
> -
> 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/

Re: How to check the kernel compile options ?

[H. Peter Anvin]

Followup to:  <4.3.2.7.2.20020204133252.00c50f00@mail.osagesoftware.com>
By author:    David Relson <relson@osagesoftware.com>
In newsgroup: linux.dev.kernel
> 
> >I have had in my /sbin/installkernel a clause to save .config as
> >config-<foo> when I install vmlinuz-<foo>; I believe anyone not doing
> >that[1] is, quite frankly, a moron.
> 
> Why not a simple patch for "make install" to do this?
> 

Good thought.  I was waiting for the various kernel build changes in
2.5 to overhaul make install, but a small thing should be doable in
2.4.  Note that if you have an /sbin/installkernel it overrides make
install -- as it should be.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

How to check the kernel compile options ?

[David Balazic]

Hi!

This problem again :-)

I purchase/download a program for linux.
It says it requires certain kernel features, for example :
CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET

How can I figure out in 5 minutes, without a kernel hacker, if
my linux system has the correct settings ?

This is a real life question, probably more suitable to ask
on some distributions mail list, but I thought I'll start here.

TIA,
david

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: How to check the kernel compile options ?

[Matti Aarnio]

On Mon, Feb 04, 2002 at 05:01:39PM +0100, David Balazic wrote:
> Hi!
> 
> This problem again :-)
> 
> I purchase/download a program for linux.
> It says it requires certain kernel features, for example :
> CONFIG_PROC_FS,CONFIG_NET,CONFIG_INET

   If it wants THOSE, it is asking for wrong abstraction layer 
   information.

   No userspace program (beside of special sysadmin tools) should
   be poking into PROC_FS.  The NET interface abstraction is already
   wrapped inside  libc.

> How can I figure out in 5 minutes, without a kernel hacker, if
> my linux system has the correct settings ?

   Good software gives clear diagnostics if some necessary facility
   is missing at runtime.

> This is a real life question, probably more suitable to ask
> on some distributions mail list, but I thought I'll start here.
> 
> TIA,
> david
> -- 
> David Balazic

/Matti Aarnio