Re: bug database braindump from the kernel summit
> Why not have the /proc/config option but instead of being plain text, > make it binary with a userspace app that can interpret it? [snip] > You'd have > 2.4.3-pre3:110101 . . . . . > 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. -- 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-- - 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/
Re: bug database braindump from the kernel summit
Why not have the /proc/config option but instead of being plain text, make it binary with a userspace app that can interpret it? [snip] You'd have 2.4.3-pre3:110101 . . . . . 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. -- 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-- - 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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > > On Mon, 2 Apr 2001, Tom Leete wrote: > > > Oliver Xymoron wrote: > > > > > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > > > > > On Sun, 1 Apr 2001, David Lang wrote: > > > > > 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. > > > > > > > > Let's hope it's not a flamewar, but here goes :) > > > > > > > > We -need- .config, but /proc/config seems 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. > > 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 - 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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: On Mon, 2 Apr 2001, Tom Leete wrote: Oliver Xymoron wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: 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. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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. 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 - 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/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Jeff Garzik wrote: > Oliver Xymoron wrote: > > On Mon, 2 Apr 2001, Tom Leete wrote: > > > 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.." - 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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > On Mon, 2 Apr 2001, Tom Leete wrote: > > 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 .' -- 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. - 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/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Tom Leete wrote: > Oliver Xymoron wrote: > > > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > > > On Sun, 1 Apr 2001, David Lang wrote: > > > > 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. > > > > > > Let's hope it's not a flamewar, but here goes :) > > > > > > We -need- .config, but /proc/config seems 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. 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.." - 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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > On Sun, 1 Apr 2001, David Lang wrote: > > > 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. > > > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems 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 -- The Daemons lurk and are dumb. -- Emerson - 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/
Re: bug database braindump from the kernel summit
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
On Mon, 2 Apr 2001, Jeff Garzik wrote:
> 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 summit
>
> "J . A . Magallon" wrote:
> > Could 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.
>
>
> > 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.
>
> > 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.
>
-
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/
Re: bug database braindump from the kernel summit
On 04.03 Jeff Garzik wrote:
> "J . A . Magallon" wrote:
> > Could 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.
>
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).
> FWIW here is our /sbin/installkernel command line usage help text, to
> give a glimpse of what it does and can do:
I know, run Cooker.
>
> 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
>
> > 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...
--
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
-
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/
Re: bug database braindump from the kernel summit
"J . A . Magallon" wrote:
> Could 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.
> 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.
> 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.
-
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/
Re: bug database braindump from the kernel summit
On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote: > On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems 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. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Re: bug database braindump from the kernel summit
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 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. -- 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 - 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/
Re: bug database braindump from the kernel summit
[EMAIL PROTECTED] (Ben Ford) wrote on 01.04.01 in <[EMAIL PROTECTED]>: > 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. > You'd have > 2.4.3-pre3:110101 . . . . . 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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Jeff Garzik wrote: > On Sun, 1 Apr 2001, David Lang wrote: > > 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. > > Let's hope it's not a flamewar, but here goes :) > > We -need- .config, but /proc/config seems 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.." - 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/
Re: bug database braindump from the kernel summit
Larry McVoy wrote: > The other main thing was to define some sort of structure to the > bug report and try and get the use to categorize if they could. > In an ideal world, we would use the maintainers file and the > stack traceback to cc the bug to the maintainer. I think we want > to explore this a bit. I'm not sure that the maintainer file is > the way to go, what if we divided it up into much broader chunks > like "fs", "vm", "network drivers", and had a mail forwarder > for each area. That could fan out to the maintainers. This depends on the bug. If someone finds a generic kernel problem while logging in on a serial terminal connected through a specialix-SX card, there is no reason to CC me as the maintainer of that driver. If however, the bug is in the driver, then I should be CC-ed. Asking the submitter is I think the only way to do this: You have a XYZ scsi Controller. Do you think this bug relates to this driver? yes/no Should the maintainer of the xyz controller be CCed?yes/no You have a Specialix SX card. Do you think this bug relates to this driver? yes/no Should the maintainer of the specialix SX card be CCed? yes/no Blindly CCing people from the Maintainers list is probably not a good idea. Better would be to allow the maintainers to specify HOW they want to be CC-ed. I for example, would want for every driver that I maintain, to have a bug submitted in my jitterbug database (instead of mailed to my private email address). > Not losing bugs > While there was much discussion about how to get rid of bad, > incorrect, and/or duplicate bug reports, several people - Alan > in particular - made the point that having a complete collection > of all bug reports was important. You can do data mining across > all/part of them and look for patterns. The point was that there > is some useful signal amongst all the noise so we do not want to > lose that signal. All this sorting and tagging should be done in ONE database. So, random users can add "count me in on this one", meaning that they too see this problem. And that someone trying to fix this can CC them too. Also, say Jens can tag a problem as "a fluke", while Alan should still be able to tag it as: "Hmm. Odd problem. Heard of it before, Need more reports to figure out the common cause". Queries to the database can then be "All problems tagged as real by at least one kernel hotshot". > Signal/noise > We had a lot of discussion about how to deal with signal/noise. > The bugzilla proponents thought we could do this with some additional > hacking to bugzilla. I, given the BitKeeper background, thought > that we could do this by having two databases, one with all the > crud in it and another with just the screened bugs in it. No matter > how it is done, there needs to be some way to both keep a full list, > which will likely be used only for data mining, and another, much > smaller list of screened bugs. Jens wants there to be a queue of > new bugs and a mechanism where people can come in the morning, pull > a pile of bugs off of the queue, sort them, sending some to the real > database. This idea has a lot of merit, it needs some pondering as > DaveM would say, to get to the point that we have a workable mechanism > which works in a distributed fashion. Jitterbug already has this. However, every problem in Jitterbug is only in one queue/classification. My suggestion for the big thingy is that everybody could have a different view. > The other key point seemed to be that if nobody picked up a bug and > nobody said that this bug should be picked up, then the bug expires > out of the pending queue. It gets stashed in the bug archive for > mining purposes and it can be resurrected if it later becomes a real > bug, but the key point seems to be that it _automatically_ disappears > out of the pending queue. I personally am very supportive of this > model. We need some way to just let junk stay junk. If junk has to > be pruned out of the system by humans, the system sucks. The system, > not humans, needs to autoprune. OK. But those "interested" in the bug (the Email of the submitter) should be notified: "Your reported bug is going to expire soon. Could you indicate that this is still bothering you"?. "Enhancement requests" can stay around for a long, long time if nobody takes the time to implement the request. Speaking of "Enhancement requests", there once was a professor in the field of "operating systems" who wanted to give out real Linux-ehancement projects as lab-projects for his course. Some people might tag enhancement requests with "80-hour project", and then allow students to do them for credit! > Simplified
Re: bug database braindump from the kernel summit
> 1) The idea of letting a bug "expire" is a good one. One way to do this > is to incorporate some form of user-base moderation into the bug > database. Unlike some of the forum systems, there's no reason why we can't > have tiers of moderators: "maintainers" are the clearinghouse people for > certain portions of the Linux kernel source tree and should have a larger > voice as to whether a bug is important, redundant, or completely off As everyone thinking about this perhaps should know, this moderation system is already used by Bugzilla: A bug report starts out as "unconfirmed", and people who volunteer to triage bugs and are given appropriate permission may elevate them to "new" status or resolve them as invalid. The actual maintainers query the database only for "new" bugs. Experience in the Mozilla development community has shown, however, that this is not as simple as it sounds. There are bug reports which remain unconfirmed for weeks. People submitting reports have that nasty feeling that they are being ignored. Really, I don't think it is a good idea to stamp any bug report as "not to be taken seriously" by default. It puts off people who know better. With automatic expiry of unconfirmed reports that would be absolutely devastating. Hopefully it is clear why. (Any pre-triaging process, even without expiry, must be done quickly and have enough people who do this unrewarding work, or it will introduce delays which make the submissions increasingly worthless.) I think that some sort of expiry is in order, but perhaps better the other way around: any report with no progress in a certain amount of time gets _higher_ priority, so that someone (perhaps a triager) is "forced" to do _something_ about it (and if it's only to close an issue which has long been fixed or is invalid from the start). Bugzilla also does address some of the other issues presented here. (No, I don't think it's perfect :-) Olaf - 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/
Re: bug database braindump from the kernel summit
1) The idea of letting a bug "expire" is a good one. One way to do this is to incorporate some form of user-base moderation into the bug database. Unlike some of the forum systems, there's no reason why we can't have tiers of moderators: "maintainers" are the clearinghouse people for certain portions of the Linux kernel source tree and should have a larger voice as to whether a bug is important, redundant, or completely off As everyone thinking about this perhaps should know, this moderation system is already used by Bugzilla: A bug report starts out as "unconfirmed", and people who volunteer to triage bugs and are given appropriate permission may elevate them to "new" status or resolve them as invalid. The actual maintainers query the database only for "new" bugs. Experience in the Mozilla development community has shown, however, that this is not as simple as it sounds. There are bug reports which remain unconfirmed for weeks. People submitting reports have that nasty feeling that they are being ignored. Really, I don't think it is a good idea to stamp any bug report as "not to be taken seriously" by default. It puts off people who know better. With automatic expiry of unconfirmed reports that would be absolutely devastating. Hopefully it is clear why. (Any pre-triaging process, even without expiry, must be done quickly and have enough people who do this unrewarding work, or it will introduce delays which make the submissions increasingly worthless.) I think that some sort of expiry is in order, but perhaps better the other way around: any report with no progress in a certain amount of time gets _higher_ priority, so that someone (perhaps a triager) is "forced" to do _something_ about it (and if it's only to close an issue which has long been fixed or is invalid from the start). Bugzilla also does address some of the other issues presented here. (No, I don't think it's perfect :-) Olaf - 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/
Re: bug database braindump from the kernel summit
Larry McVoy wrote: The other main thing was to define some sort of structure to the bug report and try and get the use to categorize if they could. In an ideal world, we would use the maintainers file and the stack traceback to cc the bug to the maintainer. I think we want to explore this a bit. I'm not sure that the maintainer file is the way to go, what if we divided it up into much broader chunks like "fs", "vm", "network drivers", and had a mail forwarder for each area. That could fan out to the maintainers. This depends on the bug. If someone finds a generic kernel problem while logging in on a serial terminal connected through a specialix-SX card, there is no reason to CC me as the maintainer of that driver. If however, the bug is in the driver, then I should be CC-ed. Asking the submitter is I think the only way to do this: You have a XYZ scsi Controller. Do you think this bug relates to this driver? yes/no Should the maintainer of the xyz controller be CCed?yes/no You have a Specialix SX card. Do you think this bug relates to this driver? yes/no Should the maintainer of the specialix SX card be CCed? yes/no Blindly CCing people from the Maintainers list is probably not a good idea. Better would be to allow the maintainers to specify HOW they want to be CC-ed. I for example, would want for every driver that I maintain, to have a bug submitted in my jitterbug database (instead of mailed to my private email address). Not losing bugs While there was much discussion about how to get rid of bad, incorrect, and/or duplicate bug reports, several people - Alan in particular - made the point that having a complete collection of all bug reports was important. You can do data mining across all/part of them and look for patterns. The point was that there is some useful signal amongst all the noise so we do not want to lose that signal. All this sorting and tagging should be done in ONE database. So, random users can add "count me in on this one", meaning that they too see this problem. And that someone trying to fix this can CC them too. Also, say Jens can tag a problem as "a fluke", while Alan should still be able to tag it as: "Hmm. Odd problem. Heard of it before, Need more reports to figure out the common cause". Queries to the database can then be "All problems tagged as real by at least one kernel hotshot". Signal/noise We had a lot of discussion about how to deal with signal/noise. The bugzilla proponents thought we could do this with some additional hacking to bugzilla. I, given the BitKeeper background, thought that we could do this by having two databases, one with all the crud in it and another with just the screened bugs in it. No matter how it is done, there needs to be some way to both keep a full list, which will likely be used only for data mining, and another, much smaller list of screened bugs. Jens wants there to be a queue of new bugs and a mechanism where people can come in the morning, pull a pile of bugs off of the queue, sort them, sending some to the real database. This idea has a lot of merit, it needs some pondering as DaveM would say, to get to the point that we have a workable mechanism which works in a distributed fashion. Jitterbug already has this. However, every problem in Jitterbug is only in one queue/classification. My suggestion for the big thingy is that everybody could have a different view. The other key point seemed to be that if nobody picked up a bug and nobody said that this bug should be picked up, then the bug expires out of the pending queue. It gets stashed in the bug archive for mining purposes and it can be resurrected if it later becomes a real bug, but the key point seems to be that it _automatically_ disappears out of the pending queue. I personally am very supportive of this model. We need some way to just let junk stay junk. If junk has to be pruned out of the system by humans, the system sucks. The system, not humans, needs to autoprune. OK. But those "interested" in the bug (the Email of the submitter) should be notified: "Your reported bug is going to expire soon. Could you indicate that this is still bothering you"?. "Enhancement requests" can stay around for a long, long time if nobody takes the time to implement the request. Speaking of "Enhancement requests", there once was a professor in the field of "operating systems" who wanted to give out real Linux-ehancement projects as lab-projects for his course. Some people might tag enhancement requests with "80-hour project", and then allow students to do them for credit! Simplified access: browsing and updating Linus
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: 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. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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.." - 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/
Re: bug database braindump from the kernel summit
[EMAIL PROTECTED] (Ben Ford) wrote on 01.04.01 in [EMAIL PROTECTED]: 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. You'd have 2.4.3-pre3:110101 . . . . . 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 - 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/
Re: bug database braindump from the kernel summit
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. -- 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 - 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/
Re: bug database braindump from the kernel summit
On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote: On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Re: bug database braindump from the kernel summit
"J . A . Magallon" wrote:
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.
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.
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.
-
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/
Re: bug database braindump from the kernel summit
On 04.03 Jeff Garzik wrote:
"J . A . Magallon" wrote:
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.
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).
FWIW here is our /sbin/installkernel command line usage help text, to
give a glimpse of what it does and can do:
I know, run Cooker.
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
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...
--
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
-
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/
Re: bug database braindump from the kernel summit
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
On Mon, 2 Apr 2001, Jeff Garzik wrote:
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 summit
"J . A . Magallon" wrote:
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.
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.
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.
-
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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: 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. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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 -- The Daemons lurk and are dumb. -- Emerson - 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/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Tom Leete wrote: Oliver Xymoron wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: 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. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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. 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.." - 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/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: On Mon, 2 Apr 2001, Tom Leete wrote: 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 .' -- 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. - 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/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Jeff Garzik wrote: Oliver Xymoron wrote: On Mon, 2 Apr 2001, Tom Leete wrote: 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.." - 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/
Re: bug database braindump from the kernel summit
On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: > Let's hope it's not a flamewar, but here goes :) > > We -need- .config, but /proc/config seems 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] - 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/
Re: bug database braindump from the kernel summit
Miles, if the system is just sending the config info it may not be a problem, but take the microsoft example, how do you know the bug report is just sending info that is relevent to the system and not trying to discover everything that you have installed in your system (in our case we can't be looking for pirated software, but assuming that the bug report is being sent as root how do you know that it's not sending out your password file if it just send 'stuff' out) David Lang On Sun, 1 Apr 2001, Miles Lane wrote: > David Lang wrote: > > > > On Sun, 1 Apr 2001, Larry McVoy wrote: > > > > when generating the auto bug reports make sure that the system tells the > > user exactly what data is being sent. > > > > sending a large chunk of unknown data off the machine is a big concern to > > many people. > > Yeah. This is a good point, although I can't think of info > about a system's hardware and software configuration that would > be particularly sensitive, other than files that contain network > topology or encrypted passwords. I'm sure others can come up > with such a list. One candidate might be the smbfs configuration > file, since network passwords can live there, right? tcpdump output > might also be sensitive, but that type of info would need to get > requested by network driver developers after the initial bug report > anyhow. > > Miles > - 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/
Re: bug database braindump from the kernel summit
David Lang wrote: > > On Sun, 1 Apr 2001, Larry McVoy wrote: > > when generating the auto bug reports make sure that the system tells the > user exactly what data is being sent. > > sending a large chunk of unknown data off the machine is a big concern to > many people. Yeah. This is a good point, although I can't think of info about a system's hardware and software configuration that would be particularly sensitive, other than files that contain network topology or encrypted passwords. I'm sure others can come up with such a list. One candidate might be the smbfs configuration file, since network passwords can live there, right? tcpdump output might also be sensitive, but that type of info would need to get requested by network driver developers after the initial bug report anyhow. Miles - 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/
Re: bug database braindump from the kernel summit
Jeff Garzik wrote: > /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 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"? > 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 - 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/
Re: bug database braindump from the kernel summit
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=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y You'd have 2.4.3-pre3:110101 . . . . . -b - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > /sbin/installkernel copies stuff into /boot, appending a version number. > > One way might be to have this script also copy the kernel config. > could be, /sbin/installkernel doesn'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 - 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: > On Sun, 1 Apr 2001, David Lang wrote: > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > /sbin/installkernel copies stuff into /boot, appending a version number. > > > One way might be to have this script also copy the kernel config. > > > could be, /sbin/installkernel doesn'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 > > > > - 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/
Re: bug database braindump from the kernel summit
could be, /sbin/installkernel doesn't exist on my systems David Lang On Sun, 1 Apr 2001, Jeff Garzik wrote: > 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 summit > > On Sun, 1 Apr 2001, David Lang wrote: > > /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. > > /sbin/installkernel copies stuff into /boot, appending a version number. > One way might be to have this script also copy the kernel config. > > 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: > > 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 > > > - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Larry McVoy wrote: > Problem details > Bug report quality [...] > But the main thing was to extract all the info we could > automatically. One thing was the machine config (hardware and > at least kernel version). The other thing was extract any oops > messages and get a stack traceback. Basically look through REPORTING-BUGS for a laundry list of helpful info. > The other main thing was to define some sort of structure to the > bug report and try and get the use to categorize if they could. > In an ideal world, we would use the maintainers file and the > stack traceback to cc the bug to the maintainer. I think we want > to explore this a bit. I'm not sure that the maintainer file is > the way to go, what if we divided it up into much broader chunks > like "fs", "vm", "network drivers", and had a mail forwarder > for each area. That could fan out to the maintainers. (slight tangent) One thing people have talked about in the past is updating MAINTAINERS to actually reflect real life... some of the active maintainers don't have maintainer entries. That may be intentional, maybe not... For drivers at least, bugs -should- be mailed to the driver maintainer where possible, which is not always the same as the subsystem maintainer. > Signal/noise [...] > Jens wants there to be a queue of Jes? > new bugs and a mechanism where people can come in the morning, pull > a pile of bugs off of the queue, sort them, sending some to the real > database. This idea has a lot of merit, it needs some pondering as > DaveM would say, to get to the point that we have a workable mechanism > which works in a distributed fashion. Back when I was hacking GNOME, various janitors (to use the now-popular term) would go through and clean the bug database, sorting through a lot of the noise. Newbies are finding the Kernel Janitors project as an excellent way to begin to contribute to the kernel. There are definitely interested, smart people willing to help, that at present don't know a lot about the kernel. Such volunteers, like the GNOMEs mentioned above, could be a vast benefit to this particular step of the bug tracking process. You http://sourceforge.net/projects/kernel-janitor/ > Past experiences > This is a catch all for sound bytes that we don't want to forget... > > - one key observation: let bugs "expire" much like news expires. If > nobody has been whining enough that it gets into the high signal > bug db then it probably isn't real. We really want a way where no > activity means let it expire. Agreed, with a caveat: some bugs should stay around but not expire. There is a class of bugs that shouldn't go away from the "less noise" bug database when there is no activity. ie. hard problems we want to remember, but solve in a later version. > Requirements 1) An e-mail interface. For sorting through massive amounts of bugs, NNTP is far more useful. Maybe as a query interface as well, NNTP is useful. But for getting into the nitty-gritty details of handling a bug, e-mail is generally the primary medium of communication between developer and user. debian-bugs assigns each bug a unique e-mail address, and all e-mail that arrives in that mailbox is appended to the bug's comments. 2) Support for binary attachments from users - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > /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. /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > 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. 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 - 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: > 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 summit > > On Sun, 1 Apr 2001, Manfred Spraul wrote: > > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > > > > > /proc/pci data 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 ;-) > > > > 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_CS > > CONFIG_PCMCIA_HERMES > > CONFIG_AIRONET4500_CS > > CONFIG_PCMCIA_IBMTR > > are missing. > > noted. > > > 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/ > - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > > > /proc/pci data 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 ;-) > 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_CS > CONFIG_PCMCIA_HERMES > CONFIG_AIRONET4500_CS > CONFIG_PCMCIA_IBMTR > are missing. noted. > 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/
Re: bug database braindump from the kernel summit
At 10:54 AM 4/1/01 -0700, Larry McVoy wrote: > - one key observation: let bugs "expire" much like news expires. If > nobody has been whining enough that it gets into the high signal > bug db then it probably isn't real. We really want a way where no > activity means let it expire. I have a couple of suggestions that may improve the bug tracking process without needing a bug czar or driving everyone crazy. 1) The idea of letting a bug "expire" is a good one. One way to do this is to incorporate some form of user-base moderation into the bug database. Unlike some of the forum systems, there's no reason why we can't have tiers of moderators: "maintainers" are the clearinghouse people for certain portions of the Linux kernel source tree and should have a larger voice as to whether a bug is important, redundant, or completely off base. "contributors" are people recognized as having contributed in one way or another to the source tree (or, as the bug systems grows to encompass documentation, the documentation tree) and could serve as a "citizens advisory group" to speed the process of sorting the wheat from the chaff. Also, a "contributor" would be able to "take ownership" of the bug. 2) One of the big problems is recognizing that a particular bug has already been reported, and more importantly getting some sort of link between the new bug and the old bug. When I ran a DVT operation, the developers found this linkage to be extremely useful in order to trace the source of bugs, especially really obscure ones that cut across a number of modules. 3) In the commercial software world, there is a requirement that a bug be verified by someone "in house" -- in other words, a bug isn't a bug until someone can reproduce it. This is a key item in separating the noise from the signal. Again, the group-moderation system would permit quick identification of repeatable bugs. 4) Using an NNTP interface would be interesting. "Follow-ups" could consist of observations, commands, and requests for additional information from the bug report that isn't visible from the basic NNTP tree. If you want to see more about a bug, the tree representation could let you pick and choose what you want to look at. For someone who prefers to have everything to hand, a command would say "email sections a, b, ... to me (with "me" defined in the NNTP headers) and those sections would be mailed to the individual. 5) Most important, the person originally submitting the bug should have an easy way of saying "never mind." Existing search commands in the NNTP interface could make this a very easy chore for the infrequent contributor. EXPIRING: It's one thing to do an expire a la standard NNTP conventions, but it's quite another to do something "smarter". I see a couple of things that would have to enter into a decision whether to expire a bug from the pending-status list: a) The bug needs to be present for more than a set amount of time without overt activity. b) A person trying to replicate the bug should be able to extend the time-out -- some bugs take longer to replicate than others. If you don't allow for this, the bug could be expired before it can be verified, and the verifier has to work harder (assuming they even bother) to extract the bug from the data mine and get it to where a code guy can get to it. c) A maintainer should be able to sink a bogus bug early, especially if no one has owned up to trying to replicate it or fix it. Contributors can heartily declare a bug "bogus", and if enough do so the bug could be sunk early. Also, if enough people say "I can't replicate this bug" that's a good sign you have a piece of noise. From my own experience in commercial shops, I'd say that we could start with an expire time of two weeks, and if necessary adjust it. Weighting for each of the metrics for expiring bugs could be set experimentally. The goal is that a maintainer can squash bugs NOW, and the community could actively squash bugs in 24 hours. IS THE BUG FIXED: When a bug is declared "fixed" the bug tracking system needs to alert everyone who has submitted the bug and replicated it. This notification would then let those people (those who are still interested) see if the patch really fixes the bug. If it does, confirmation of a bug fix would be included, and that would help Alan & Co. to determine what patches should go in. Just a few random thoughts on the whole process -- but I suspect others have already thought of these things. I'd be interested in working on this, day job willing. Stephen Satchell [EMAIL PROTECTED] - 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/
Re: bug database braindump from the kernel summit
From: "Jeff Garzik" <[EMAIL PROTECTED]> > > /proc/pci data 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_CS CONFIG_PCMCIA_HERMES CONFIG_AIRONET4500_CS CONFIG_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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. David Lang - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Albert D. Cahalan wrote: > Manfred Spraul writes: > > [Larry McVoy] > > >> There was a lot of discussion about possible tools > >> that would dig out the /proc/pci info > > 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. > > 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 - 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/
Re: bug database braindump from the kernel summit
oops, I was going to quote a section from Larry's mail then decided not to and forgot to delete the header. David Lang On Sun, 1 Apr 2001, David Lang wrote: > Date: Sun, 1 Apr 2001 14:16:57 -0700 (PDT) > From: David Lang <[EMAIL PROTECTED]> > To: Larry McVoy <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: bug database braindump from the kernel summit > > On Sun, 1 Apr 2001, Larry McVoy wrote: > > when generating the auto bug reports make sure that the system tells the > user exactly what data is being sent. > > sending a large chunk of unknown data off the machine is a big concern to > many people. > > David Lang > > > - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: > > There was a lot of discussion about possible tools > > that would dig out the /proc/pci info > > 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. 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 - 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/
Re: bug database braindump from the kernel summit
Gregory Maxwell writes: > On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: >> I'm really sick of being buried in useless information. The signal >> gets lost in the noise. It is easy to discard automatically generated >> bug reports, and way too annoying to wade through the crud. >> >> When network connections hang, the console-tools package version >> isn't likely to be of any use. When ramfs leaks memory, nobody needs >> the content of /proc/pci. >> >> Sometimes the bit of crud are HUGE. Imagine the hardware info >> for a 64-way SGI or Sun box with plenty of devices attached. > > Disk space is 'free'. Disk space isn't the issue. Just a few days ago I tried to help somebody who posted one of the bloated fill-in-the-form bug reports. I gave him a useless answer, because I didn't see amid all the junk that he had no problems with a 2.2.xx kernel. The good information had been buried in fluff. - 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/
Re: bug database braindump from the kernel summit
On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: > I'm really sick of being buried in useless information. The signal > gets lost in the noise. It is easy to discard automatically generated > bug reports, and way too annoying to wade through the crud. > > When network connections hang, the console-tools package version > isn't likely to be of any use. When ramfs leaks memory, nobody needs > the content of /proc/pci. > > Sometimes the bit of crud are HUGE. Imagine the hardware info > for a 64-way SGI or Sun box with plenty of devices attached. Disk space is 'free'. The information should be stored in a database where you can retrieve the information you need at will, while the back-end can statistically analyze the whole of the information looking for anomalies you would never have expected (like that network hang actually being caused by console-tools :) ). - 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/
Re: bug database braindump from the kernel summit
Manfred Spraul writes: > [Larry McVoy] >> There was a lot of discussion about possible tools >> that would dig out the /proc/pci info > > 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. 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. - 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/
Re: bug database braindump from the kernel summit
> Problem details > Bug report quality > There was lots of discussion on this. The main agreement was that we > wanted the bug reporting system to dig out as much info as possible > and prefill that. There was a lot of discussion about possible tools > that would dig out the /proc/pci info; there was discussion about > Andre's tools which can tell you if you can write your disk; someone > else had something similar. > > But the main thing was to extract all the info we could > automatically. One thing was the machine config (hardware and > at least kernel version). The other thing was extract any oops > messages and get a stack traceback. I'm really sick of being buried in useless information. The signal gets lost in the noise. It is easy to discard automatically generated bug reports, and way too annoying to wade through the crud. When network connections hang, the console-tools package version isn't likely to be of any use. When ramfs leaks memory, nobody needs the content of /proc/pci. Sometimes the bit of crud are HUGE. Imagine the hardware info for a 64-way SGI or Sun box with plenty of devices attached. - 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/
Re: bug database braindump from the kernel summit
> There was a lot of discussion about possible tools > that would dig out the /proc/pci info 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 - 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/
Re: bug database braindump from the kernel summit
There was a lot of discussion about possible tools that would dig out the /proc/pci info 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 - 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/
Re: bug database braindump from the kernel summit
Problem details Bug report quality There was lots of discussion on this. The main agreement was that we wanted the bug reporting system to dig out as much info as possible and prefill that. There was a lot of discussion about possible tools that would dig out the /proc/pci info; there was discussion about Andre's tools which can tell you if you can write your disk; someone else had something similar. But the main thing was to extract all the info we could automatically. One thing was the machine config (hardware and at least kernel version). The other thing was extract any oops messages and get a stack traceback. I'm really sick of being buried in useless information. The signal gets lost in the noise. It is easy to discard automatically generated bug reports, and way too annoying to wade through the crud. When network connections hang, the console-tools package version isn't likely to be of any use. When ramfs leaks memory, nobody needs the content of /proc/pci. Sometimes the bit of crud are HUGE. Imagine the hardware info for a 64-way SGI or Sun box with plenty of devices attached. - 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/
Re: bug database braindump from the kernel summit
On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: I'm really sick of being buried in useless information. The signal gets lost in the noise. It is easy to discard automatically generated bug reports, and way too annoying to wade through the crud. When network connections hang, the console-tools package version isn't likely to be of any use. When ramfs leaks memory, nobody needs the content of /proc/pci. Sometimes the bit of crud are HUGE. Imagine the hardware info for a 64-way SGI or Sun box with plenty of devices attached. Disk space is 'free'. The information should be stored in a database where you can retrieve the information you need at will, while the back-end can statistically analyze the whole of the information looking for anomalies you would never have expected (like that network hang actually being caused by console-tools :) ). - 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/
Re: bug database braindump from the kernel summit
Manfred Spraul writes: [Larry McVoy] There was a lot of discussion about possible tools that would dig out the /proc/pci info 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. 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. - 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/
Re: bug database braindump from the kernel summit
Gregory Maxwell writes: On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: I'm really sick of being buried in useless information. The signal gets lost in the noise. It is easy to discard automatically generated bug reports, and way too annoying to wade through the crud. When network connections hang, the console-tools package version isn't likely to be of any use. When ramfs leaks memory, nobody needs the content of /proc/pci. Sometimes the bit of crud are HUGE. Imagine the hardware info for a 64-way SGI or Sun box with plenty of devices attached. Disk space is 'free'. Disk space isn't the issue. Just a few days ago I tried to help somebody who posted one of the bloated fill-in-the-form bug reports. I gave him a useless answer, because I didn't see amid all the junk that he had no problems with a 2.2.xx kernel. The good information had been buried in fluff. - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: There was a lot of discussion about possible tools that would dig out the /proc/pci info 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. 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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Albert D. Cahalan wrote: Manfred Spraul writes: [Larry McVoy] There was a lot of discussion about possible tools that would dig out the /proc/pci info 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. 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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. David Lang - 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/
Re: bug database braindump from the kernel summit
oops, I was going to quote a section from Larry's mail then decided not to and forgot to delete the header. David Lang On Sun, 1 Apr 2001, David Lang wrote: Date: Sun, 1 Apr 2001 14:16:57 -0700 (PDT) From: David Lang [EMAIL PROTECTED] To: Larry McVoy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: bug database braindump from the kernel summit On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. David Lang - 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/
Re: bug database braindump from the kernel summit
From: "Jeff Garzik" [EMAIL PROTECTED] /proc/pci data 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_CS CONFIG_PCMCIA_HERMES CONFIG_AIRONET4500_CS CONFIG_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 - 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/
Re: bug database braindump from the kernel summit
At 10:54 AM 4/1/01 -0700, Larry McVoy wrote: - one key observation: let bugs "expire" much like news expires. If nobody has been whining enough that it gets into the high signal bug db then it probably isn't real. We really want a way where no activity means let it expire. I have a couple of suggestions that may improve the bug tracking process without needing a bug czar or driving everyone crazy. 1) The idea of letting a bug "expire" is a good one. One way to do this is to incorporate some form of user-base moderation into the bug database. Unlike some of the forum systems, there's no reason why we can't have tiers of moderators: "maintainers" are the clearinghouse people for certain portions of the Linux kernel source tree and should have a larger voice as to whether a bug is important, redundant, or completely off base. "contributors" are people recognized as having contributed in one way or another to the source tree (or, as the bug systems grows to encompass documentation, the documentation tree) and could serve as a "citizens advisory group" to speed the process of sorting the wheat from the chaff. Also, a "contributor" would be able to "take ownership" of the bug. 2) One of the big problems is recognizing that a particular bug has already been reported, and more importantly getting some sort of link between the new bug and the old bug. When I ran a DVT operation, the developers found this linkage to be extremely useful in order to trace the source of bugs, especially really obscure ones that cut across a number of modules. 3) In the commercial software world, there is a requirement that a bug be verified by someone "in house" -- in other words, a bug isn't a bug until someone can reproduce it. This is a key item in separating the noise from the signal. Again, the group-moderation system would permit quick identification of repeatable bugs. 4) Using an NNTP interface would be interesting. "Follow-ups" could consist of observations, commands, and requests for additional information from the bug report that isn't visible from the basic NNTP tree. If you want to see more about a bug, the tree representation could let you pick and choose what you want to look at. For someone who prefers to have everything to hand, a command would say "email sections a, b, ... to me (with "me" defined in the NNTP headers) and those sections would be mailed to the individual. 5) Most important, the person originally submitting the bug should have an easy way of saying "never mind." Existing search commands in the NNTP interface could make this a very easy chore for the infrequent contributor. EXPIRING: It's one thing to do an expire a la standard NNTP conventions, but it's quite another to do something "smarter". I see a couple of things that would have to enter into a decision whether to expire a bug from the pending-status list: a) The bug needs to be present for more than a set amount of time without overt activity. b) A person trying to replicate the bug should be able to extend the time-out -- some bugs take longer to replicate than others. If you don't allow for this, the bug could be expired before it can be verified, and the verifier has to work harder (assuming they even bother) to extract the bug from the data mine and get it to where a code guy can get to it. c) A maintainer should be able to sink a bogus bug early, especially if no one has owned up to trying to replicate it or fix it. Contributors can heartily declare a bug "bogus", and if enough do so the bug could be sunk early. Also, if enough people say "I can't replicate this bug" that's a good sign you have a piece of noise. From my own experience in commercial shops, I'd say that we could start with an expire time of two weeks, and if necessary adjust it. Weighting for each of the metrics for expiring bugs could be set experimentally. The goal is that a maintainer can squash bugs NOW, and the community could actively squash bugs in 24 hours. IS THE BUG FIXED: When a bug is declared "fixed" the bug tracking system needs to alert everyone who has submitted the bug and replicated it. This notification would then let those people (those who are still interested) see if the patch really fixes the bug. If it does, confirmation of a bug fix would be included, and that would help Alan Co. to determine what patches should go in. Just a few random thoughts on the whole process -- but I suspect others have already thought of these things. I'd be interested in working on this, day job willing. Stephen Satchell [EMAIL PROTECTED] - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: From: "Jeff Garzik" [EMAIL PROTECTED] /proc/pci data 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 ;-) 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_CS CONFIG_PCMCIA_HERMES CONFIG_AIRONET4500_CS CONFIG_PCMCIA_IBMTR are missing. noted. 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: 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 summit On Sun, 1 Apr 2001, Manfred Spraul wrote: From: "Jeff Garzik" [EMAIL PROTECTED] /proc/pci data 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 ;-) 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_CS CONFIG_PCMCIA_HERMES CONFIG_AIRONET4500_CS CONFIG_PCMCIA_IBMTR are missing. noted. 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/ - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: /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. /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: 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. 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 - 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: 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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Larry McVoy wrote: Problem details Bug report quality [...] But the main thing was to extract all the info we could automatically. One thing was the machine config (hardware and at least kernel version). The other thing was extract any oops messages and get a stack traceback. Basically look through REPORTING-BUGS for a laundry list of helpful info. The other main thing was to define some sort of structure to the bug report and try and get the use to categorize if they could. In an ideal world, we would use the maintainers file and the stack traceback to cc the bug to the maintainer. I think we want to explore this a bit. I'm not sure that the maintainer file is the way to go, what if we divided it up into much broader chunks like "fs", "vm", "network drivers", and had a mail forwarder for each area. That could fan out to the maintainers. (slight tangent) One thing people have talked about in the past is updating MAINTAINERS to actually reflect real life... some of the active maintainers don't have maintainer entries. That may be intentional, maybe not... For drivers at least, bugs -should- be mailed to the driver maintainer where possible, which is not always the same as the subsystem maintainer. Signal/noise [...] Jens wants there to be a queue of Jes? new bugs and a mechanism where people can come in the morning, pull a pile of bugs off of the queue, sort them, sending some to the real database. This idea has a lot of merit, it needs some pondering as DaveM would say, to get to the point that we have a workable mechanism which works in a distributed fashion. Back when I was hacking GNOME, various janitors (to use the now-popular term) would go through and clean the bug database, sorting through a lot of the noise. Newbies are finding the Kernel Janitors project as an excellent way to begin to contribute to the kernel. There are definitely interested, smart people willing to help, that at present don't know a lot about the kernel. Such volunteers, like the GNOMEs mentioned above, could be a vast benefit to this particular step of the bug tracking process. You http://sourceforge.net/projects/kernel-janitor//plug Past experiences This is a catch all for sound bytes that we don't want to forget... - one key observation: let bugs "expire" much like news expires. If nobody has been whining enough that it gets into the high signal bug db then it probably isn't real. We really want a way where no activity means let it expire. Agreed, with a caveat: some bugs should stay around but not expire. There is a class of bugs that shouldn't go away from the "less noise" bug database when there is no activity. ie. hard problems we want to remember, but solve in a later version. Requirements 1) An e-mail interface. For sorting through massive amounts of bugs, NNTP is far more useful. Maybe as a query interface as well, NNTP is useful. But for getting into the nitty-gritty details of handling a bug, e-mail is generally the primary medium of communication between developer and user. debian-bugs assigns each bug a unique e-mail address, and all e-mail that arrives in that mailbox is appended to the bug's comments. 2) Support for binary attachments from users - 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/
Re: bug database braindump from the kernel summit
could be, /sbin/installkernel doesn't exist on my systems David Lang On Sun, 1 Apr 2001, Jeff Garzik wrote: 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 summit On Sun, 1 Apr 2001, David Lang wrote: /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. /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. 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/
Re: bug database braindump from the kernel summit
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 On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. could be, /sbin/installkernel doesn'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 - 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/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. could be, /sbin/installkernel doesn'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 - 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/
Re: bug database braindump from the kernel summit
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=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y You'd have 2.4.3-pre3:110101 . . . . . -b - 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/
Re: bug database braindump from the kernel summit
David Lang wrote: On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. Yeah. This is a good point, although I can't think of info about a system's hardware and software configuration that would be particularly sensitive, other than files that contain network topology or encrypted passwords. I'm sure others can come up with such a list. One candidate might be the smbfs configuration file, since network passwords can live there, right? tcpdump output might also be sensitive, but that type of info would need to get requested by network driver developers after the initial bug report anyhow. Miles - 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/
Re: bug database braindump from the kernel summit
Jeff Garzik wrote: snip /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 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"? 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 - 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/
Re: bug database braindump from the kernel summit
Miles, if the system is just sending the config info it may not be a problem, but take the microsoft example, how do you know the bug report is just sending info that is relevent to the system and not trying to discover everything that you have installed in your system (in our case we can't be looking for pirated software, but assuming that the bug report is being sent as root how do you know that it's not sending out your password file if it just send 'stuff' out) David Lang On Sun, 1 Apr 2001, Miles Lane wrote: David Lang wrote: On Sun, 1 Apr 2001, Larry McVoy wrote: when generating the auto bug reports make sure that the system tells the user exactly what data is being sent. sending a large chunk of unknown data off the machine is a big concern to many people. Yeah. This is a good point, although I can't think of info about a system's hardware and software configuration that would be particularly sensitive, other than files that contain network topology or encrypted passwords. I'm sure others can come up with such a list. One candidate might be the smbfs configuration file, since network passwords can live there, right? tcpdump output might also be sensitive, but that type of info would need to get requested by network driver developers after the initial bug report anyhow. Miles - 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/
Re: bug database braindump from the kernel summit
On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems 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] - 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/
