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 a
Chip Salzenberg <[EMAIL PROTECTED]> writes:
|> 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
** 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 in
On Fri, Sep 01, 2000 at 02:27:39PM +0200, Andi Kleen 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 platfo
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 a
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 show
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 ot
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 [EMAI
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 solve
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. acc
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 i
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, so
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 thi
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
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
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 wo
Keith Owens writes:
> Having one directory per installed kernel containing vmlinux, map,
> config, build symlink, modules and any future kernel related data makes
> sense.
Hear, hear. I'm in this camp.
I think there should be one build target: "make linux" and one install
target: "make install"
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 n
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 ver
>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 e
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, wonderfu
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
locate
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 u
** 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... doh!
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 [EMA
>> 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 line
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 bod
** 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 configurati
** 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 suggestion
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 con
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 ge
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 fai
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. Unfortun
> > 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 b
> 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 cumulative
[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 mis-read
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 thi
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 an
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 ide
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 kern
> 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 the
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 tha
On Wed, Aug 30, 2000 at 10:36:09AM -0500, you [Timur Tabi] claimed:
> ** 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 ker
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 PROTECTED]>
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 T
63 matches
Mail list logo
