Folks, since bug tracking is the next thing we are attacking here at
BitMover, I have a great deal of interest in the bug tracking discussion
which happened last night at the summit. We already have a prototyped bug
tracking system which we are integrating into BitKeeper, but as usual,
it isn't good enough for the kernel team who have an interesting set
of requirements.
We want to make sure that the BK bug tracking system _could_ be used for
the kernel effort. Whether it is or not will be decided after years of
licensing flamewars, etc., etc. We're not going to go there so please
don't try.
Where I want to go is a discussion of requirements, then we converge on
a strawman proposal, and then all of the people who care enough about
this can go implement an answer and Linus and/or Alan and/or whoever can
choose one.
Let's stay focussed on arriving at a good set of agreed on requirements.
I've done a brain dump below. I'll track this mail thread and update this
doc as the discussion unfolds. I'll post updates as it is needed. If this
discussion takes on a life of its own, I may try and grab all the mail and
archive it so that people can browse; we'll see, it may be that everyone
is so busy that this will be the first and last message on the topic.
--lm
Brain dump on the bug tracking problem from the Kernel Summit discussions
[SCCS/s.BUGS vers 1.2 2001/04/01 10:46:55]
Outline
Problems
Problem details
Past experiences
Requirements
Problems
- getting quality bug reports
- not losing any bugs
- sorting low signal vs high signal into a smaller high signal pile
- simplified, preferably NNTP, access to the bug database (Linus
would use this; he's unlikely to use anything else)
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.
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.
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.
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.
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.
Simplified access: browsing and updating
Linus made the point that mailing lists suck. He isn't on any and
refuses to join any. He reads lists with a news reader. I think
people should sit up and listen to that - it's a key point. If your
mailing list isn't gatewayed to a newsgroup, he isn't reading it and
a lot of other people aren't either.
There was a fair bit of discussion about how to get the bug database
connected to news. There doesn't seem to be any reason that the
bug system couldn't be a news server/gateway. You should be able to
browse
bitbucket.kernel.bugs - all the unscreened crud
screened.kernel.bugs - all bugs which have been screened
fs.kernel.bugs - screened bugs in the "fs" category
ext2.kernel.bugs - screened bugs in the "ext2" category
eepro.kernel.bugs - screened bugs in the "eepro" category
etc.
Furthermore, the bugs should be structured once they are screened,
i.e., they have a set of fields like (this is a strawman):
Synopsis - one line man-page like summary of the bug
Severity - how critical is this bug?
Priority - how soon does it need to be fixed?
Category - subsystem in which the bug occurs
Description - details on the bug, oops, stack trace, etc.
Hardware - hardware info
Software - kernel version, glibc version, etc.
Suggested fix - any suggestion on how to fix it
Interest list - set of email addresses and/or newsgroups for updates
It ought to work that if someone posts a followup to the bug then if
the followup changes any of the fields that gets propagated to the
underlying bug database. If this is done properly the news reader will
be the only interface that most people use.
Past experiences
This is a catch all for sound bytes that we don't want to forget...
- Sorting bugs by hand is a pain in the ass (Ted burned out on it and
Alan refuses to say that it is the joy of his life to do it)
- bug systems tend to "get in the way". Unless they are really trivial
to submit, search, update then people get tired of using them and go
back to the old way
- 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.
- Alan pointed out that having all of the bugs someplace is useful,
you can search through the 200 similar bugs and notice that SMP
is the common feature.
Requirements
This section is mostly empty, it's here as a catch all for people's
bullet items.
- it would be very nice to be able to cross reference bugs to bug fixes
in the source management system, as well as the other way around.
> 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
> 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.
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 :) ).
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.
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.
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
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
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
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
>
>
>
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
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]
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
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
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
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/
>
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
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
>
>
>
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
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
>
>
>
>
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
>
>
>
>
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:1101111100000100000000 . . . . .
-b
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
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
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
>
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]
> 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
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 made the point that mailing lists suck. He isn't on any and
> refuses to join any. He reads lists with a news reader. I think
> people should sit up and listen to that - it's a key point. If your
> mailing list isn't gatewayed to a newsgroup, he isn't reading it and
> a lot of other people aren't either.
>
> There was a fair bit of discussion about how to get the bug database
> connected to news. There doesn't seem to be any reason that the
> bug system couldn't be a news server/gateway. You should be able to
> browse
> bitbucket.kernel.bugs - all the unscreened crud
> screened.kernel.bugs - all bugs which have been screened
> fs.kernel.bugs - screened bugs in the "fs" category
> ext2.kernel.bugs - screened bugs in the "ext2" category
> eepro.kernel.bugs - screened bugs in the "eepro" category
This sounds good, except that when you have different views towards
the database, problems arise. We could just dump the database into a
news-server every hour to make Linus happy, but that would probably
defeat some of the advantages of the "news" interface (mark problems
as "read").
> - 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.
This needs to be "forced". A submitter should get an EMail when a bug
is about to be expired, and should be able to claim an extension. The
reply should also ask for the latest kernel that the submitter tried,
and was verfied to have the bug.
So the bug item in the DB will get tagged for example as: reported to
exist on 2.4.1, 2.4.2-ac12 and 2.4.3 by REW.
- Dynamic keyword section.
Dynamic: You CAN enter keywords that are not already in the database.
Those will be available to others from then on.
Someone may want to tag "disc-problem" as equivalent to "disk-problem".
The "limited list of possibilites" means that searches for...
> - Alan pointed out that having all of the bugs someplace is useful,
> you can search through the 200 similar bugs and notice that SMP
> is the common feature.
... similar problems become easier/possible.
- Automatic inclusion of ".config" files. Nowadays, the .config is so
large that submitting it with a bugreport is not efficient. However,
if you would be submitting a bugreport into a database, the info could
be very useful in reliably scanning for common configuration options
in a set of reports.
- "me too" reports should be able to append a new ".config" to an
existing bugreport.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
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.."
[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:1101111100000100000000 . . . . .
Another option would be to put a checksum of the config, and still keep
the config separate - at least you could tell if you had the right config
for the kernel.
MfG Kai
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.
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
"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.
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.
>
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
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
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.."
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.
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.."
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
> 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:1101111100000100000000 . . . . .
>
I think this is against UNIX/Linux philosophy... Why we wouldn't just
providing all the interface through sysctl stuff and abadon all the
/proc? Cause we want to provide human-readable interface, which could
be parsed really simply...
We should just mean 'cat' as 'userspace app' primarily i think. At least
currently we does. Also you have a big problem with forward compatibility
etc.
But anyway i would vote for the .config file somewhere in /boot directory.
If one have a kernel from some linux distribution, it is propably actually
obsolete, so it is proximity the bug is actually fixed anyway. And if he
will get the newest kernel, it should do something like cp .config /boot/config.
--
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------