bug database braindump from the kernel summit
Quoted 2 lines
There was a lot of discussion about possible tools that would dig out the
/proc/pciinfo
I think the tools should not dig too much information out of the system. I remember some Microsoft (win98 beta?) bugtracking software that insisted on sending a several hundert kB long compressed blob with every bug report.
IMHO it must be possible to file bugreports without the complete hw info if I know that the bug isn't hw related.
--
Manfred
Quoted 11 lines · Manfred Spraul
[Larry McVoy]
Quoted 2 lines
There was a lot of discussion about possible tools that would dig out the
/proc/pciinfoI think the tools should not dig too much information out of the system. I remember some Microsoft (win98 beta?) bugtracking software that insisted on sending a several hundert kB long compressed blob with every bug report.
IMHO it must be possible to file bugreports without the complete hw info if I know that the bug isn't hw related.
Yep. The two hardware-related items that usually matter:
Little-endian or broken-endian?
32-bit or 64-bit?
The CPU type is not necessary or sufficient, since one can often run a 32-bit kernel on 64-bit hardware and at least MIPS has both little-endian and broken-endian supported.
Quoted 9 lines · Manfred Spraul
Quoted 2 lines
There was a lot of discussion about possible tools that would dig out the
/proc/pciinfoI think the tools should not dig too much information out of the system. I remember some Microsoft (win98 beta?) bugtracking software that insisted on sending a several hundert kB long compressed blob with every bug report.
IMHO it must be possible to file bugreports without the complete hw info if I know that the bug isn't hw related.
Two comments --
* It's only disk space. It's better to have and not need, than need and not have. Please do give me 200kb bug reports! :)
* There should be a way to allow the user to omit hw info, because the user may not want to disclose some parts of their system.
Regards,
Jeff
Quoted 13 lines · Albert D. Cahalan
Quoted 11 lines · Manfred Spraul
[Larry McVoy]
Quoted 2 lines
There was a lot of discussion about possible tools that would dig out the
/proc/pciinfoI think the tools should not dig too much information out of the system. I remember some Microsoft (win98 beta?) bugtracking software that insisted on sending a several hundert kB long compressed blob with every bug report.
IMHO it must be possible to file bugreports without the complete hw info if I know that the bug isn't hw related.
Quoted 4 lines
Yep. The two hardware-related items that usually matter:
Little-endian or broken-endian?
32-bit or 64-bit?
Matters to whom? You, or the people actually fixing bugs?
"Broken-endian"? whatever.
/proc/pci data alone with every bug report is usually invaluable. It gives you a really good idea of the general layout of the system, and you can often catch or become aware of related hardware characteristics which
linux/REPORTINGS-BUGS was created to give users a hint that we need -more- information, and tells exactly what general information is useful to provide. We do not need less information.
Jeff
From: "Jeff Garzik" <[email protected]>
Quoted 2 lines
/proc/pcidata alone with every bug report is usually invaluable.
Even if the bug is a compile error?
E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected Description:
Several config options are missing in the 'if' at the end of linux/drivers/net/pcmcia/Config.in.
This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the kernel won't link.
CONFIG_ARCNET_COM20020_CSCONFIG_PCMCIA_HERMESCONFIG_AIRONET4500_CSCONFIG_PCMCIA_IBMTR
are missing.
Obviously too much data doesn't hurt, as long as
* it's hidden somewhere deep in a database, clearly separated from the important parts (if there is an oops: decoded oops, description, how easy is it to trigger the bug, steps to reproduce)
* very easy for the bug reporter to collect.
* not mandatory.
--
Manfred
Quoted 5 lines · Manfred Spraul
From: "Jeff Garzik" <[email protected]>
Quoted 2 lines
/proc/pcidata alone with every bug report is usually invaluable.Even if the bug is a compile error?
In fact, yes. Having the tuple of: .config, /proc/pci, and compile error output, you can see additionally if the user is doing something wrong.
It allows you to fix the user as well as the compile error ;-)
Quoted 9 lines
E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected Description:
Several config options are missing in the 'if' at the end of linux/drivers/net/pcmcia/Config.in.
This means thatCONFIG_PCMCIA_NETCARDis not set, and then (iirc) the kernel won't link.
Quoted 5 lines
CONFIG_ARCNET_COM20020_CSCONFIG_PCMCIA_HERMESCONFIG_AIRONET4500_CSCONFIG_PCMCIA_IBMTR
are missing.
noted.
Quoted 6 lines
Obviously too much data doesn't hurt, as long as
* it's hidden somewhere deep in a database, clearly separated from the important parts (if there is an oops: decoded oops, description, how easy is it to trigger the bug, steps to reproduce)
* very easy for the bug reporter to collect.
* not mandatory.
agreed.
Regards,
Jeff
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old /proc/config flamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.
David Lang
Quoted 60 lines · Jeff Garzik
Date: Sun, 1 Apr 2001 17:48:34 -0500 (CDT)
From: Jeff Garzik <[email protected]>
To: Manfred Spraul <[email protected]>
Cc: Albert D. Cahalan <[email protected]>, [email protected],
[email protected]
Subject: Re: bug database braindump from the kernel summitQuoted 5 lines · Manfred Spraul
From: "Jeff Garzik" <[email protected]>
Quoted 2 lines
/proc/pcidata alone with every bug report is usually invaluable.Even if the bug is a compile error?
In fact, yes. Having the tuple of: .config,
/proc/pci, and compile error output, you can see additionally if the user is doing something wrong.It allows you to fix the user as well as the compile error ;-)
Quoted 9 lines
E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected Description:
Several config options are missing in the 'if' at the end of linux/drivers/net/pcmcia/Config.in.
This means thatCONFIG_PCMCIA_NETCARDis not set, and then (iirc) the kernel won't link.Quoted 5 lines
CONFIG_ARCNET_COM20020_CSCONFIG_PCMCIA_HERMESCONFIG_AIRONET4500_CSCONFIG_PCMCIA_IBMTR
are missing.noted.
Quoted 6 lines
Obviously too much data doesn't hurt, as long as
* it's hidden somewhere deep in a database, clearly separated from the important parts (if there is an oops: decoded oops, description, how easy is it to trigger the bug, steps to reproduce)
* very easy for the bug reporter to collect.
* not mandatory.agreed.
Regards,
Jeff
-
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/
Quoted 4 lines · David Lang
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old
/proc/configflamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.
Let's hope it's not a flamewar, but here goes :)
We -need- .config, but /proc/config seems like pure bloat.
If a sysadmin (note I don't say "user") has no clue what his kernel config is, or has no clue what kernel is running on his box, then they should be fired before the day is out.
Jeff
Jeff, if the sysadmin had anything to do with setting up the box I would agree with you, but there are cases where one person will boot a machine and another will then need to find out what is going on.
I have seen systems with multiple kernels available on boot get booted from the wrong kernel
I've also seen a machine running for years without being touched and then a sysadmin is hired and has to work on it, how should they know what the config was?
/proc/config may be bloat, but we do need a way for the kernel config to be tied to the kernel image that is running, however it is made available.
David Lang
Quoted 9 lines · Jeff Garzik
If a sysadmin (note I don't say "user") has no clue what his kernel config is, or has no clue what kernel is running on his box, then they should be fired before the day is out.
Jeff
Quoted 2 lines · David Lang
/proc/configmay be bloat, but we do need a way for the kernel config to be tied to the kernel image that is running, however it is made available.
/sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config.
Jeff
could be, /sbin/installkernel doesn't exist on my systems
David Lang
Quoted 20 lines · Jeff Garzik
Date: Sun, 1 Apr 2001 18:34:07 -0500 (CDT)
From: Jeff Garzik <[email protected]>
To: David Lang <[email protected]>
Cc: Manfred Spraul <[email protected]>,
Albert D. Cahalan <[email protected]>, [email protected], [email protected]
Subject: Re: bug database braindump from the kernel summitQuoted 2 lines · David Lang
/proc/configmay be bloat, but we do need a way for the kernel config to be tied to the kernel image that is running, however it is made available.
/sbin/installkernelcopies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config.Jeff
Quoted 5 lines · David Lang
Quoted 2 lines · Jeff Garzik
/sbin/installkernelcopies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config.could be,
/sbin/installkerneldoesn't exist on my systems
arch/i386/boot/install.sh has been calling /sbin/installkernel, if it exists, for a good while now.
It sounds like your kernel or initscripts package is incomplete. You can grab installkernel off a Mandrake- or RedHat-based system.
Jeff
Jeff, my point was that not all systems will have this script. also it won't do you any good if the system you are compiling on is not the same system the kernel will be running on
but we are starting the wrong discussion here :-)
David Lang
Quoted 18 lines · Jeff Garzik
Quoted 5 lines · David Lang
Quoted 2 lines · Jeff Garzik
/sbin/installkernelcopies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config.could be,
/sbin/installkerneldoesn't exist on my systems
arch/i386/boot/install.shhas been calling/sbin/installkernel, if it exists, for a good while now.It sounds like your kernel or initscripts package is incomplete. You can grab installkernel off a Mandrake- or RedHat-based system.
Jeff
Why not have the /proc/config option but instead of being plain text, make it binary with a userspace app that can interpret it?
It could have a signature as to kernel version + patches and the rest would be just bits.
Instead of:
CONFIG_X86=yCONFIG_ISA=y
# CONFIG_SBUS is not setCONFIG_UID16=y
You'd have
2.4.3-pre3:1101111100000100000000 . . . . .
-b
Jeff Garzik wrote:
<snip>
Quoted 4 lines
/proc/pcidata alone with every bug report is usually invaluable. It gives you a really good idea of the general layout of the system, and you can often catch or become aware of related hardware characteristics which
I often see requests for the output of "lspci -vvxxx" when developers are looking into problems with handling pci bus bridging and quirks in specific hardware. For example, this info has been requested of me for debugging a problem handling my Neomagic 2160, at least one bug in early Yenta code and so on. Does /proc/pci get you all the information that would be obtained with "lspci -vvxxx"?
Quoted 3 lines
linux/REPORTINGS-BUGS was created to give users a hint that we need -more- information, and tells exactly what general information is useful to provide. We do not need less information.
Agreed.
Miles
Quoted 3 lines · Jeff Garzik
Let's hope it's not a flamewar, but here goes :)
We -need- .config, but
/proc/configseems like pure bloat.
Don't ask me for sample code, but...
The init code for many drivers is freed up after it's used. Could we apply the same technique and compile in .config, then printk the entire lot (boot option) and free up the space afterwards?
FlatCap (Richard Russon)
[email protected]
Quoted 9 lines · Jeff Garzik
Quoted 4 lines · David Lang
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old
/proc/configflamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.Let's hope it's not a flamewar, but here goes :)
We -need- .config, but
/proc/configseems like pure bloat.
As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
[email protected] (Ben Ford) wrote on 01.04.01 in <[email protected]>:
Quoted 8 lines
Why not have the
/proc/configoption but instead of being plain text, make it binary with a userspace app that can interpret it?It could have a signature as to kernel version + patches and the rest would be just bits.
You'd have
2.4.3-pre3:1101111100000100000000 . . . . .
Another option would be to put a checksum of the config, and still keep the config separate - at least you could tell if you had the right config for the kernel.
MfG Kai
Quoted 11 lines · Richard Russon
Quoted 3 lines · Jeff Garzik
Let's hope it's not a flamewar, but here goes :)
We -need- .config, but
/proc/configseems like pure bloat.Don't ask me for sample code, but...
The init code for many drivers is freed up after it's used. Could we apply the same technique and compile in .config, then printk the entire lot (boot option) and free up the space afterwards?
Though this would save memory at run-time, you'd still increase the size of the image.
Signature · 2 lines
-Steven Freedom is the freedom to say that two plus two equals four.
Quoted 7 lines · On 04.02 Oliver Xymoron wrote:
As a former proponent of
/proc/config(I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in/boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue.
Could <installkernel> make part of the kernel scripts, or in one other standard software package, like modutils, so its versions are controlled and can be requested (in Doc/ChageLog, like other things) ?
Perhaps it could be put into a kernel-utils package with ksymoops, and standarise the places and naming. I do not know if systems like Caldera, SuSE or Debian adopted the /boot place for kernel things (standard kernels still come with INSTALL_PATH=/boot commented-out), or the vmlinuz-X.Y.Z naming.
I think the best solution would be to make /boot the 'official' place for kernels, the -X.Y.Z naming an standard, installkernel should save System.map and .config.
And you can add something like /proc/signature/map, /proc/signature/config, etc to md5-check if a certain file fits running kernel.
Signature · 4 lines
J.A. Magallon # Let the source mailto:[email protected] # be with you, Luke... Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686
Quoted 2 lines · J . A . Magallon
Could <installkernel> make part of the kernel scripts, or in one other standard software package, like modutils, so its versions are controlled
There is value in putting it into the Linux kernel source tree, in linux/scripts dir. But most vendors can and should take this script as a sample, and customize it for their distro. The Linux-Mandrake installkernel script definitely gets touched every so often, and decisions it makes, like updating lilo.conf or grub/menu.lst, or autodetecting the boot loader, are definitely not to be applied for all cases.
FWIW here is our /sbin/installkernel command line usage help text, to give a glimpse of what it does and can do:
Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE
-l: Add a lilo entry -i: Dont generate Initrd files -n: Don't launch lilo. -g: Add a Grub entry. -d: Don't autodetect boot loader. -a: Autodetect boot loader. -r: Features for RPM post install. -c: Don't copy files. -q: Be quiet. -h: This help.
Quoted 3 lines
I think the best solution would be to make /boot the 'official' place for kernels, the -X.Y.Z naming an standard, installkernel should save System.map and .config.
There will never be an official place to put this stuff, because that's a distro policy decision. A quick search just now reveals no reference to /boot in the i386 Makefiles, and only a quick reference in the README file.
Quoted 2 lines
And you can add something like
/proc/signature/map,/proc/signature/config, etc to md5-check if a certain file fits running kernel.
Additionally, everyone should remember: /proc is not a dumping ground :)
Ad-hoc naming like this has created the procfs namespace ugliness we have now... let's not add to it unless we have to, and unless we have a good idea of proper naming.
Signature · 3 lines
Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door.
the reason for suggesting /proc is that this data needs to be available in a standard place, putting it in the kernel image (compressed is fine, bitmap is fine) eliminates the problems of trying to dictate where in the filesystem the distros need to put things.
putting it in /proc _somewhere_ (/proc/sys/kernel/config any better???) avoids the need to invent a new place to put it.
one person suggested that instead of listing all the options in a nice human readable format we could change it to a series of flags, that won't quite work as there are three values for most options (Y,N,M) not to mentions the ones that allow more values. you could still just list all the config values without including the stuff to the left of the = it would require matching up with the kernel version specific config file to tell what is what but would cut down on the space needed.
David Lang
proc is overused, but putting the compile options
Quoted 61 lines · Jeff Garzik
Date: Mon, 02 Apr 2001 18:09:05 -0400
From: Jeff Garzik <[email protected]>
To: J . A . Magallon <[email protected]>
Cc: Oliver Xymoron <[email protected]>, David Lang <[email protected]>,
Manfred Spraul <[email protected]>,
Albert D . Cahalan <[email protected]>, [email protected], [email protected]
Subject: Re: bug database braindump from the kernel summitQuoted 2 lines · J . A . Magallon
Could <installkernel> make part of the kernel scripts, or in one other standard software package, like modutils, so its versions are controlled
There is value in putting it into the Linux kernel source tree, in linux/scripts dir. But most vendors can and should take this script as a sample, and customize it for their distro. The Linux-Mandrake installkernel script definitely gets touched every so often, and decisions it makes, like updating lilo.conf or grub/menu.lst, or autodetecting the boot loader, are definitely not to be applied for all cases.
FWIW here is our
/sbin/installkernelcommand line usage help text, to give a glimpse of what it does and can do:Usage: ${0##*/} -[lngarhcq]
KERNEL_VERSIONBOOTIMAGE MAPFILE-l: Add a lilo entry -i: Dont generate Initrd files -n: Don't launch lilo. -g: Add a Grub entry. -d: Don't autodetect boot loader. -a: Autodetect boot loader. -r: Features for RPM post install. -c: Don't copy files. -q: Be quiet. -h: This help.Quoted 3 lines
I think the best solution would be to make /boot the 'official' place for kernels, the -X.Y.Z naming an standard, installkernel should save System.map and .config.
There will never be an official place to put this stuff, because that's a distro policy decision. A quick search just now reveals no reference to /boot in the i386 Makefiles, and only a quick reference in the README file.
Quoted 2 lines
And you can add something like
/proc/signature/map,/proc/signature/config, etc to md5-check if a certain file fits running kernel.Additionally, everyone should remember: /proc is not a dumping ground :)
Ad-hoc naming like this has created the procfs namespace ugliness we have now... let's not add to it unless we have to, and unless we have a good idea of proper naming.
--
Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door.
Quoted 4 lines · On 04.03 Jeff Garzik wrote:
Quoted 2 lines · J . A . Magallon
Could <installkernel> make part of the kernel scripts, or in one other standard software package, like modutils, so its versions are controlled
Quoted 8 lines
There is value in putting it into the Linux kernel source tree, in linux/scripts dir. But most vendors can and should take this script as a sample, and customize it for their distro. The Linux-Mandrake installkernel script definitely gets touched every so often, and decisions it makes, like updating lilo.conf or grub/menu.lst, or autodetecting the boot loader, are definitely not to be applied for all cases.
I think that should be split in two, one thing is building and install a kernel and one other is add the entry in your bootloader config ('update-bootloader', for example, that looks into /boot and adds missing entries).
Quoted 2 lines
FWIW here is our
/sbin/installkernelcommand line usage help text, to give a glimpse of what it does and can do:
I know, run Cooker.
Quoted 5 lines
There will never be an official place to put this stuff, because that's a distro policy decision. A quick search just now reveals no reference to /boot in the i386 Makefiles, and only a quick reference in the README file.
linux/Makefile, #INSTALL_PATH=/boot
Quoted 4 lines
Quoted 3 lines
And you can add something like
/proc/signature/map,/proc/signature/config, etc to md5-check if a certain file fits running kernel.
I usually think about /proc like the way to do a 'cat' instead of a 'syscall', in this case to ask kernel for various md5 sigs,
but of course you can always write a user app that queries kernel and prints result for your scripting pleasure...
Signature · 4 lines
J.A. Magallon # Let the source mailto:[email protected] # be with you, Luke... Linux werewolf 2.4.3 #2 SMP Fri Mar 30 15:42:05 CEST 2001 i686
Quoted 11 lines · Oliver Xymoron
Quoted 8 lines · Jeff Garzik
Quoted 4 lines · David Lang
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old
/proc/configflamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.Let's hope it's not a flamewar, but here goes :)
Quoted 7 lines
Quoted 1 line
We -need- .config, but
/proc/configseems like pure bloat.As a former proponent of
/proc/config(I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in/boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue.
How about /lib/modules/$(uname -r)/build/.config ? It's already there.
Tom
Signature · 1 line
The Daemons lurk and are dumb. -- Emerson
Quoted 14 lines · Tom Leete
Quoted 13 lines · Oliver Xymoron
Quoted 9 lines · Jeff Garzik
Quoted 4 lines · David Lang
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old
/proc/configflamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.Let's hope it's not a flamewar, but here goes :)
We -need- .config, but
/proc/configseems like pure bloat.
Quoted 7 lines
Quoted 5 lines
As a former proponent of
/proc/config(I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in/boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue.How about /lib/modules/$(uname -r)/build/.config ? It's already there.
It'd be great if we got away from the config being hidden too.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 4 lines · Oliver Xymoron
Quoted 1 line · Tom Leete
How about /lib/modules/$(uname -r)/build/.config ? It's already there.
It'd be great if we got away from the config being hidden too.
When exporting it outside the kernel tree, the '.' prefix should definitely be stripped... My preference is /boot/config-2.4.3 (with /boot/config as a symlink to it)
Assuming your initscripts is smart about updating /boot symlinks, any running kernel config [properly installed] can be grabbed with a simple 'cp /boot/config .'
Signature · 3 lines
Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door.
Quoted 8 lines · Jeff Garzik
Quoted 4 lines · Oliver Xymoron
Quoted 1 line · Tom Leete
How about /lib/modules/$(uname -r)/build/.config ? It's already there.
It'd be great if we got away from the config being hidden too.
When exporting it outside the kernel tree, the '.' prefix should definitely be stripped...
I think the same should be true for the new build system as well.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 23 lines · Oliver Xymoron
Quoted 20 lines · Tom Leete
Quoted 18 lines · Oliver Xymoron
Quoted 9 lines · Jeff Garzik
Quoted 4 lines · David Lang
if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old
/proc/configflamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script.Let's hope it's not a flamewar, but here goes :)
We -need- .config, but
/proc/configseems like pure bloat.As a former proponent of
/proc/config(I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in/boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue.
Quoted 3 lines
Quoted 1 line
How about /lib/modules/$(uname -r)/build/.config ? It's already there.
It'd be great if we got away from the config being hidden too.
How about adding a config tag that gets spit out along an OOPS message. We could add a flag to ksymoops that would cause that flag to be read and the corresponding .config info to get looked up (mechanism to be determined). This might reduce the chances of "new kernel tester" reporting an OOPS but sending in the wrong .config data.
Miles
Quoted 2 lines
Why not have the
/proc/configoption but instead of being plain text, make it binary with a userspace app that can interpret it?
[snip]
Quoted 3 lines
You'd have
2.4.3-pre3:1101111100000100000000 . . . . .
I think this is against UNIX/Linux philosophy... Why we wouldn't just providing all the interface through sysctl stuff and abadon all the /proc? Cause we want to provide human-readable interface, which could be parsed really simply...
We should just mean 'cat' as 'userspace app' primarily i think. At least currently we does. Also you have a big problem with forward compatibility etc.
But anyway i would vote for the .config file somewhere in /boot directory. If one have a kernel from some linux distribution, it is propably actually obsolete, so it is proximity the bug is actually fixed anyway. And if he will get the newest kernel, it should do something like cp .config /boot/config.
Signature · 13 lines
Peter "Pasky" Baudis Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. -- Keith Owens <[email protected]> in linux-kernel My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s++:++ a--- C+++ UL++++$ P+ L+++ E--- W+ N !o K- w-- !O M- !V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y? ------END GEEK CODE BLOCK------