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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
> 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 ?
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > 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 ?
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
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.
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
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
David Balazic <[email protected]> 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??...
> > 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.
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
Followup to: <[email protected]>
By author: David Relson <[email protected]>
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.
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
At 01:22 PM 2/4/02, you wrote:
>Followup to: <[email protected]>
>By author: David Relson <[email protected]>
>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?
On Mon, 04 Feb 2002 13:34:40 -0500,
David Relson <[email protected]> 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
Followup to: <[email protected]>
By author: Daniel Phillips <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: David Relson <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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:[email protected]
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
On February 4, 2002 11:11 pm, H. Peter Anvin wrote:
> By author: Daniel Phillips <[email protected]>
> > 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
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--On Monday, 04 February, 2002 10:22 AM -0800 "H. Peter Anvin"
<[email protected]> 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
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
> 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
> 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
[email protected] 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 <[email protected]> 303-666-0315
Nelson Computing of Boulder Colorado
Networking/Contracting/Custom Software/Linux Fast and Personal service
[email protected] 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
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][email protected])
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
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
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
On Wed, 6 Feb 2002 [email protected] 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 ([email protected]) (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.
> > 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
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
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
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 --
[email protected]
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.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> 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
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
--On Wednesday, 06 February, 2002 4:31 PM +0100 Christoph Rohland
<[email protected]> 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
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
Marco Colombo <[email protected]> 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
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 --
[email protected]
(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.
Alan Cox <[email protected]> said:
> "Christoph Rohland" at Feb 06, 2002 11:36:56 AM said:
> X-Mailer: ELM [version 2.5 PL6]
> MIME-Version: 1.0
> Sender: [email protected]
> Precedence: bulk
> X-Mailing-List: [email protected]
> 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
> 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
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.
_____/ _____/ _/ [email protected]
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 --
[email protected]
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
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
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
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
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
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
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
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
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
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
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
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
On Thu, 7 Feb 2002 13:08:23 -0800, Mike Touloumtzis
<[email protected]> 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
Ville Herva <[email protected]> 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
On Thu, Feb 07, 2002 at 10:11:44PM +0100, you [Horst von Brand] wrote:
> Ville Herva <[email protected]> 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 --
[email protected]
Daniel Phillips <[email protected]> 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
On February 8, 2002 09:53 pm, Horst von Brand wrote:
> Daniel Phillips <[email protected]> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
--On Thursday, 07 February, 2002 12:34 PM -0800 Mike Touloumtzis
<[email protected]> 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
--On Thursday, 07 February, 2002 1:08 PM -0800 Mike Touloumtzis
<[email protected]> 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
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
On Fri, 8 Feb 2002, Horst von Brand wrote:
| Daniel Phillips <[email protected]> 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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
>> > 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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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: [email protected]
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.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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/
In article <[email protected]>,
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
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 --
[email protected]
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/
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
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/
"Randy.Dunlap" <[email protected]> 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
Daniel Phillips <[email protected]> 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
On February 13, 2002 03:19 pm, Horst von Brand wrote:
> Daniel Phillips <[email protected]> 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
On Wed, 13 Feb 2002, Horst von Brand wrote:
> Daniel Phillips <[email protected]> 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.
On Wed, 13 Feb 2002, Richard B. Johnson wrote:
| On Wed, 13 Feb 2002, Horst von Brand wrote:
|
| > Daniel Phillips <[email protected]> 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
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 <[email protected]> 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.
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 <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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 <[email protected]>.
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/
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
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
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/
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
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 - [email protected] - http://www.devcon.net
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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/
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
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 - [email protected] - http://www.devcon.net
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 - [email protected] - http://www.devcon.net
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