On Thu, 31 Aug 2000, Alan Cox wrote:
> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful. But I do want /proc/config.gz in the kernel.
>
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you
On Thu, 31 Aug 2000, Alan Cox wrote:
/lib/modules/version/.config is a big step up from the current situation
and I'm grateful. But I do want /proc/config.gz in the kernel.
So cat it with a magic lead in after the bzImage gzip block into the bzImage.
If you dont even know what file you
** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Fri, 01 Sep 2000
11:10:49 +1100
> Having one directory per installed kernel containing vmlinuz, map,
> config, build symlink, modules and any future kernel related data makes
> sense.
I agree. This idea gets my vote!
--
Timur Tabi
** Reply to message from Keith Owens [EMAIL PROTECTED] on Fri, 01 Sep 2000
11:10:49 +1100
Having one directory per installed kernel containing vmlinuz, map,
config, build symlink, modules and any future kernel related data makes
sense.
I agree. This idea gets my vote!
--
Timur Tabi -
On Mon, Sep 04, 2000 at 12:24:02PM +0200, Werner Almesberger wrote:
> Philipp Rumpf wrote:
> > Most architectures can boot ELF images -- defining section names for
> > .config.gz and the version string in the ELF file can be done in an
> > architecture-independent fashion.
>
> Yep, then add some
Philipp Rumpf wrote:
> isn't that what the version string (/proc/version at runtime, start_sys
> in the bzImage) is for ?
Hmm yes, that should be good enough.
> Most architectures can boot ELF images -- defining section names for
> .config.gz and the version string in the ELF file can be done
Philipp Rumpf wrote:
isn't that what the version string (/proc/version at runtime, start_sys
in the bzImage) is for ?
Hmm yes, that should be good enough.
Most architectures can boot ELF images -- defining section names for
.config.gz and the version string in the ELF file can be done in an
On Mon, Sep 04, 2000 at 12:24:02PM +0200, Werner Almesberger wrote:
Philipp Rumpf wrote:
Most architectures can boot ELF images -- defining section names for
.config.gz and the version string in the ELF file can be done in an
architecture-independent fashion.
Yep, then add some magic
On Fri, Sep 02, 2000 at 03:41:33PM +0200, Werner Almesberger wrote:
> Alan Cox wrote:
> > My goal would be to ensure that the bootloader didnt need to be modified.
>
> Yes, I was commenting on Andi's proposal. I think it's very important to
> avoid the need for boot loader modifications - there
On Fri, Sep 01, 2000 at 01:28:08PM +0100, Alan Cox wrote:
> > On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
> > > I don't see the advantage over Alan's proposal of simply adding the
> > > config data to the bzImage or whatever is the most common format on
> > > the respective
Pavel Machek wrote:
> > maintains all the useful information and will be less than 1/2kB.
> > (things marked as not set or modular aren't relevant to the zImage)
>
> Wrong. some modular options have efects on image (adding hooks, etc.)
Also switching between different -preN versions doesn't
On Fri, Sep 01, 2000 at 01:28:08PM +0100, Alan Cox wrote:
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
I don't see the advantage over Alan's proposal of simply adding the
config data to the bzImage or whatever is the most common format on
the respective platform.
Hi!
> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful. But I do want /proc/config.gz in the kernel.
>
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you are running for kernel you have
Hi!
> maintains all the useful information and will be less than 1/2kB.
> (things marked as not set or modular aren't relevant to the zImage)
Wrong. some modular options have efects on image (adding hooks, etc.)
Pavel
--
I'm
Andi Kleen wrote:
> I just don't see much advantage in a bzImage anymore, given the disk sizes
> of modern computers.
My floppies are still 1.44MB ...
> For kernel debugging I prefer to have an unpacked vmlinux with symbol table.
Agreed, it's more elegant.
> Would it be that hard to make lilo
Alan Cox wrote:
> My goal would be to ensure that the bootloader didnt need to be modified.
Yes, I was commenting on Andi's proposal. I think it's very important to
avoid the need for boot loader modifications - there are simply too many
of them nowadays.
> As to the tool argument - looking for
> On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
> > I don't see the advantage over Alan's proposal of simply adding the
> > config data to the bzImage or whatever is the most common format on
> > the respective platform. You still have the same fundamental problem
> > to
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
> I don't see the advantage over Alan's proposal of simply adding the
> config data to the bzImage or whatever is the most common format on
> the respective platform. You still have the same fundamental problem
> to solve (i.e.
Andi Kleen wrote:
> I'm not sure I understand the question. It would basically work like
> booting in BSD or most other Unixes: the bootloader knows ext2 and
> reads a filename that you pass as a command line option or a default
> from /. That file name would be available in the environment that
Jan-Benedict Glaw wrote:
> On Thu, Aug 31, 2000 at 04:26:55PM +0200, [EMAIL PROTECTED] wrote:
> > But what about GRUB, LOADLIN, SILO, MILO, ... ?)
>
> I've written scripts do copy any useful piece of (debug) info to
> /boot. To cope with MILO, you can use:
Actually, this was a trick question,
On Fri, Sep 01, 2000 at 02:04:44PM +0200, [EMAIL PROTECTED] wrote:
> Andi Kleen wrote:
> > What you need is a bootloader than can read uncompressed vmlinux directly,
> > and use that for booting. Then you can always directly extract the System.map
> > out of the vmlinux using nm or gdb.
>
> And
Andi Kleen wrote:
> What you need is a bootloader than can read uncompressed vmlinux directly,
> and use that for booting. Then you can always directly extract the System.map
> out of the vmlinux using nm or gdb.
And then pass this information to the soon to be running system via e.g.
an initrd
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
>
> I for one can't even keep two files straight - my kernel is forever
> getting out of synch with my System.map. Of course, I may be the only
> person that has ever had this happen to them. ;-) I am all for
> idiot-proofing
On Fri, Sep 01, 2000 at 11:01:30AM +0200, Andi Kleen wrote:
> On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
> > I for one can't even keep two files straight - my kernel is forever
> > getting out of synch with my System.map. Of course, I may be the only
> > person that has
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
> Nathan Paul Simons wrote:
> > As for the argument of putting it in the kernel being more robust and
> > idiot-proof, well, if someone can't keep three files and one directory
> > straight for each different configuration
On Thu, Aug 31, 2000 at 02:52:56PM +0200, you [[EMAIL PROTECTED]] claimed:
>
> Does also include the build number (i.e. the first part of
> UTS_VERSION) ? Is it resilient to patches where, by accident,
> EXTRAVERSION or such hasn't been incremented ? Will people always
Speaking of patches, it
On Thu, Aug 31, 2000 at 02:52:56PM +0200, you [[EMAIL PROTECTED]] claimed:
Does version also include the build number (i.e. the first part of
UTS_VERSION) ? Is it resilient to patches where, by accident,
EXTRAVERSION or such hasn't been incremented ? Will people always
Speaking of patches,
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
Nathan Paul Simons wrote:
As for the argument of putting it in the kernel being more robust and
idiot-proof, well, if someone can't keep three files and one directory
straight for each different configuration of the
On Fri, Sep 01, 2000 at 11:01:30AM +0200, Andi Kleen wrote:
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
I for one can't even keep two files straight - my kernel is forever
getting out of synch with my System.map. Of course, I may be the only
person that has ever had
On Thu, Aug 31, 2000 at 04:48:59PM +0200, Daniel Phillips wrote:
I for one can't even keep two files straight - my kernel is forever
getting out of synch with my System.map. Of course, I may be the only
person that has ever had this happen to them. ;-) I am all for
idiot-proofing things
Andi Kleen wrote:
What you need is a bootloader than can read uncompressed vmlinux directly,
and use that for booting. Then you can always directly extract the System.map
out of the vmlinux using nm or gdb.
And then pass this information to the soon to be running system via e.g.
an initrd ?
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
I don't see the advantage over Alan's proposal of simply adding the
config data to the bzImage or whatever is the most common format on
the respective platform. You still have the same fundamental problem
to solve (i.e.
On Fri, Sep 01, 2000 at 02:23:57PM +0200, [EMAIL PROTECTED] wrote:
I don't see the advantage over Alan's proposal of simply adding the
config data to the bzImage or whatever is the most common format on
the respective platform. You still have the same fundamental problem
to solve (i.e.
Andi Kleen wrote:
I just don't see much advantage in a bzImage anymore, given the disk sizes
of modern computers.
My floppies are still 1.44MB ...
For kernel debugging I prefer to have an unpacked vmlinux with symbol table.
Agreed, it's more elegant.
Would it be that hard to make lilo
On Thu, 31 Aug 2000 15:08:49 -0400 (EDT),
Chris Meadors <[EMAIL PROTECTED]> wrote:
>What about those of us who don't have modules enabled. "make
>modules_install" complains.
>
>I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules
>for modules. Or on my machines I won't even
According to Paul Gortmaker:
> (things marked as not set or modular aren't relevant to the zImage)
True, but reconstructing the (b)zImage isn't the only purpose of
keeping a config file around. So I'd rather keep the modular
settings. But maybe that's just me.
--
Chip Salzenberg
What about those of us who don't have modules enabled. "make
modules_install" complains.
I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules
for modules. Or on my machines I won't even have to create /lib/modules.
On Thu, 31 Aug 2000, Robert Greimel wrote:
> It would be
Robert Greimel writes:
>> BTW, /boot/System.map-`uname -r` is the first place in which
>> procps looks for the the System.map data. Red Hat and Debian
>
> Yes, but it is no good if you switch between different kernel
> versions as you will get error messages about System.map being
> the wrong
>BTW, /boot/System.map-`uname -r` is the first place in which
>procps looks for the the System.map data. Red Hat and Debian
Yes, but it is no good if you switch between different kernel versions as
you will get error messages about System.map being the wrong version number
(unless you copied it
Alan Cox writes:
>> where you overwrite your old kernel image with a new one without
>> rebooting instantly).
>>
>> But is it so much more expensive than a /proc/config.whatever ?
>
> Use that argument 50 times and your kernel has grown 100K.
If I get the same level of benefit 50 times,
Michael Elizabeth Chastain writes:
> I'm beginning to think that installation should copy everyting
> (bzImage, System.map, modules) into /lib/modules/. This split
> between resident and modules just causes endless hassle.
That would be a serious error. Often /boot is a special partition
On Thu, Aug 31, 2000 at 04:26:55PM +0200, [EMAIL PROTECTED] wrote:
> Or can we have a standard, reasonably reliable way for determining the
> path name of the currently running image ? (E.g. for LILO, the command
> is lilo -I `sed '/.*BOOT_IMAGE=\([^ ]*\).*/s//\1/' But what about GRUB, LOADLIN,
Timur Tabi said once upon a time (Thu, 31 Aug 2000):
> Of course, the smartest thing would be if the installation routine actually
> built the kernel, with all options finely tuned to the hardware. If I'm
> installing on a single CPU system, then I don't want the SMP kernel. Red Hat
> doesn't
** Reply to message from Paul Jakma <[EMAIL PROTECTED]> on Thu, 31 Aug 2000 17:55:49
+0100 (IST)
> as well as .config to /lib/modules//config.
>
> (i had to meant to write .config not System.map originally as that is
> what the thread is about... doh!)
>
> whatever, there's no need for kernel
On Thu, 31 Aug 2000, Robert Greimel wrote:
> It would be nice if "make modules_install" would automatically copy System.map
> to /lib/modules// .
>
as well as .config to /lib/modules//config.
(i had to meant to write .config not System.map originally as that is
what the thread is about...
I'm beginning to think that installation should copy everyting
(bzImage, System.map, modules) into /lib/modules/. This split
between resident and modules just causes endless hassle.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
>> cp System.map /boot/System.map-
>
>or even better cp to /lib/modules// and fix the tools to look
>there if they don't do already.
It would be nice if "make modules_install" would automatically copy System.map
to /lib/modules// .
Greetings
Robert
-
To unsubscribe from this list: send the
On Thu, 31 Aug 2000, Paul Jakma wrote:
> May i suggest the following:
>
> cp System.map /boot/System.map-
or even better cp to /lib/modules// and fix the tools to look
there if they don't do already.
--paulj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
** Reply to message from Daniel Phillips
<[EMAIL PROTECTED]> on Thu, 31 Aug 2000 16:48:59
+0200
> > As for the argument of putting it in the kernel being more robust and
> > idiot-proof, well, if someone can't keep three files and one directory
> > straight for each different
** Reply to message from Nathan Paul Simons <[EMAIL PROTECTED]> on Thu, 31
Aug 2000 07:24:28 -0600
> i agree with Alan, and for more than just the above reason. One of
> the rules of thumb where i work is "keep that sh*t out of our kernel!". i
> don't see what the problem is with just putting
** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 31 Aug 2000
11:49:34 +1100
> >Wow, this is incredibly useful!!! Why, or why, isn't this part of the standard
> >kernel?!?!? It would save so many headaches building kernels.
>
> Because it is easier to solve the problem in user
Alan Cox wrote:
>
> > > So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> > > If you dont even know what file you are running for kernel you have other
> > > problems anyway
> >
> > Does also include the build number (i.e. the first part of
>
> Reread my
Nathan Paul Simons wrote:
> As for the argument of putting it in the kernel being more robust and
> idiot-proof, well, if someone can't keep three files and one directory
> straight for each different configuration of the kernel that they want to
> play with, they probably shouldn't be
Nathan Paul Simons wrote:
> kernel configs with the same kernel version. Since you will probably be
> changing the EXTRAVERSION variable anyway (to differentiate between different
How about addining an additional item to the config scripts: a "build
id". This can be any random string. It just
Alan Cox wrote:
> Use that argument 50 times and your kernel has grown 100K. Unfortunately
> everyone keeps using the argument and forgetting the cumulative effect
:-) The thing is that this information is something you access when
something is already going wrong. So avoiding a few possible
Alan Cox wrote:
> > > So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> > > If you dont even know what file you are running for kernel you have other
> > > problems anyway
> >
> > Does also include the build number (i.e. the first part of
>
> Reread my suggestion.
On Thu, Aug 31, 2000 at 02:46:36PM +0100, Alan Cox wrote:
> > where you overwrite your old kernel image with a new one without
> > rebooting instantly).
> >
> > But is it so much more expensive than a /proc/config.whatever ?
>
> Use that argument 50 times and your kernel has grown 100K.
> > So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> > If you dont even know what file you are running for kernel you have other
> > problems anyway
>
> Does also include the build number (i.e. the first part of
Reread my suggestion. Its part of the bzImage file
> where you overwrite your old kernel image with a new one without
> rebooting instantly).
>
> But is it so much more expensive than a /proc/config.whatever ?
Use that argument 50 times and your kernel has grown 100K. Unfortunately
everyone keeps using the argument and forgetting the
[EMAIL PROTECTED] wrote:
> Alan Cox wrote:
>> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> Granted, all those are borderline cases, but then 1-2 kB doesn't look
> like too high a price to pay for a solution that is inherently robust.
Ah, sorry, I first
Alan Cox wrote:
> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful. But I do want /proc/config.gz in the kernel.
>
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you are running for kernel
In article <[EMAIL PROTECTED]> you wrote:
> maintains all the useful information and will be less than 1/2kB.
> (things marked as not set or modular aren't relevant to the zImage)
*bzzzt* Wrong.
Things marked as modular _do_ affect the current kernel. A lot. Granted, most
drivers don't, but
Chip Salzenberg wrote:
>
> This is a 2.2.17pre20 refresh of the /proc/config.gz patch
[...]
> +include/linux/config_data.h: newversion scripts/bin2c
> + gzip -9 < .config | scripts/bin2c kernel_config_data > $@
> +
If you are going to store options the kernel was built with, you
might
> /lib/modules//.config is a big step up from the current situation
> and I'm grateful. But I do want /proc/config.gz in the kernel.
So cat it with a magic lead in after the bzImage gzip block into the bzImage.
If you dont even know what file you are running for kernel you have other
problems
So cat it with a magic lead in after the bzImage gzip block into the bzImage.
If you dont even know what file you are running for kernel you have other
problems anyway
Does version also include the build number (i.e. the first part of
Reread my suggestion. Its part of the bzImage file
On Thu, Aug 31, 2000 at 02:46:36PM +0100, Alan Cox wrote:
where you overwrite your old kernel image with a new one without
rebooting instantly).
But is it so much more expensive than a /proc/config.whatever ?
Use that argument 50 times and your kernel has grown 100K. Unfortunately
Alan Cox wrote:
Use that argument 50 times and your kernel has grown 100K. Unfortunately
everyone keeps using the argument and forgetting the cumulative effect
:-) The thing is that this information is something you access when
something is already going wrong. So avoiding a few possible
Nathan Paul Simons wrote:
kernel configs with the same kernel version. Since you will probably be
changing the EXTRAVERSION variable anyway (to differentiate between different
How about addining an additional item to the config scripts: a "build
id". This can be any random string. It just
Nathan Paul Simons wrote:
As for the argument of putting it in the kernel being more robust and
idiot-proof, well, if someone can't keep three files and one directory
straight for each different configuration of the kernel that they want to
play with, they probably shouldn't be
** Reply to message from Keith Owens [EMAIL PROTECTED] on Thu, 31 Aug 2000
11:49:34 +1100
Wow, this is incredibly useful!!! Why, or why, isn't this part of the standard
kernel?!?!? It would save so many headaches building kernels.
Because it is easier to solve the problem in user space.
** Reply to message from Nathan Paul Simons [EMAIL PROTECTED] on Thu, 31
Aug 2000 07:24:28 -0600
i agree with Alan, and for more than just the above reason. One of
the rules of thumb where i work is "keep that sh*t out of our kernel!". i
don't see what the problem is with just putting the
** Reply to message from Daniel Phillips
[EMAIL PROTECTED] on Thu, 31 Aug 2000 16:48:59
+0200
As for the argument of putting it in the kernel being more robust and
idiot-proof, well, if someone can't keep three files and one directory
straight for each different configuration of
On Thu, 31 Aug 2000, Paul Jakma wrote:
May i suggest the following:
cp System.map /boot/System.map-release
or even better cp to /lib/modules/release/ and fix the tools to look
there if they don't do already.
--paulj
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 31 Aug 2000, Robert Greimel wrote:
It would be nice if "make modules_install" would automatically copy System.map
to /lib/modules/release/ .
as well as .config to /lib/modules/release/config.
(i had to meant to write .config not System.map originally as that is
what the thread is
On Thu, Aug 31, 2000 at 04:26:55PM +0200, [EMAIL PROTECTED] wrote:
Or can we have a standard, reasonably reliable way for determining the
path name of the currently running image ? (E.g. for LILO, the command
is lilo -I `sed '/.*BOOT_IMAGE=\([^ ]*\).*/s//\1/' /proc/cmdline`
But what about
Michael Elizabeth Chastain writes:
I'm beginning to think that installation should copy everyting
(bzImage, System.map, modules) into /lib/modules/release. This split
between resident and modules just causes endless hassle.
That would be a serious error. Often /boot is a special partition
Alan Cox writes:
where you overwrite your old kernel image with a new one without
rebooting instantly).
But is it so much more expensive than a /proc/config.whatever ?
Use that argument 50 times and your kernel has grown 100K.
If I get the same level of benefit 50 times, wonderful!
With
BTW, /boot/System.map-`uname -r` is the first place in which
procps looks for the the System.map data. Red Hat and Debian
Yes, but it is no good if you switch between different kernel versions as
you will get error messages about System.map being the wrong version number
(unless you copied it
Robert Greimel writes:
BTW, /boot/System.map-`uname -r` is the first place in which
procps looks for the the System.map data. Red Hat and Debian
Yes, but it is no good if you switch between different kernel
versions as you will get error messages about System.map being
the wrong version
According to Paul Gortmaker:
(things marked as not set or modular aren't relevant to the zImage)
True, but reconstructing the (b)zImage isn't the only purpose of
keeping a config file around. So I'd rather keep the modular
settings. But maybe that's just me.
--
Chip Salzenberg -
On Thu, 31 Aug 2000 15:08:49 -0400 (EDT),
Chris Meadors [EMAIL PROTECTED] wrote:
What about those of us who don't have modules enabled. "make
modules_install" complains.
I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules
for modules. Or on my machines I won't even have
On Thu, 31 Aug 2000, Keith Owens wrote:
> Before Rusty tells me that not everybody uses modules,
> /lib/modules/ can exist even if the kernel has no modules, it
> just needs a simple Makefile change. Think of /lib/modules/
> as a standard place to store information about kernel .
I like the
On Thu, Aug 31, 2000 at 11:49:34AM +1100, Keith Owens wrote:
> Before Rusty tells me that not everybody uses modules,
> /lib/modules/ can exist even if the kernel has no modules, it
> just needs a simple Makefile change. Think of /lib/modules/
> as a standard place to store information about
> Because it is easier to solve the problem in user space.
I have to disagree with Keith here. It's more reliable to solve the
problem in kernel space. /proc/config.gz is guaranteed to hold the
configuration of the running kernel (if it exists at all). But
/lib/modules//.config might match
On Wed, 30 Aug 2000 10:36:09 -0500,
Timur Tabi <[EMAIL PROTECTED]> wrote:
>** Reply to message from Chip Salzenberg <[EMAIL PROTECTED]> on Tue, 29 Aug 2000
>18:27:20 -0700
>> +CONFIG_PROC_CONFIG
>> + Say Y here if you want a copy of your current kernel configuration
>> + saved in the kernel
** Reply to message from Chip Salzenberg <[EMAIL PROTECTED]> on Tue, 29 Aug 2000
18:27:20 -0700
> +CONFIG_PROC_CONFIG
> + Say Y here if you want a copy of your current kernel configuration
> + saved in the kernel that you build. This is extremely useful if you
> + ever build more than one
According to Andi Kleen:
> You probably don't have a .config.gz that is longer than a page
> (4K), because in that case it'll badly corrupt your memory (or you
> just haven't noticed the corruption yet ;)
Hm... they're all <4K, but a few are pushing it.
--
Chip Salzenberg - a.k.a.
On Tue, Aug 29, 2000 at 06:27:20PM -0700, Chip Salzenberg wrote:
> This is a 2.2.17pre20 refresh of the /proc/config.gz patch originally
> created by, well, here are the credits:
>
> Oliver Xymoron <[EMAIL PROTECTED]> Jan 15 1999
> Derived from a patch by Nicholas Leon <[EMAIL
** Reply to message from Chip Salzenberg [EMAIL PROTECTED] on Tue, 29 Aug 2000
18:27:20 -0700
+CONFIG_PROC_CONFIG
+ Say Y here if you want a copy of your current kernel configuration
+ saved in the kernel that you build. This is extremely useful if you
+ ever build more than one kernel.
This is a 2.2.17pre20 refresh of the /proc/config.gz patch originally
created by, well, here are the credits:
Oliver Xymoron <[EMAIL PROTECTED]> Jan 15 1999
Derived from a patch by Nicholas Leon <[EMAIL PROTECTED]> with
suggestions from Michael Chastain <[EMAIL PROTECTED]> and Peter
90 matches
Mail list logo
