> 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 interfa
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 o
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,
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
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
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
<[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:
> > Coul
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 v
"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
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
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
[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 bi
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
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
> 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
>
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
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 loo
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 p
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 -vv
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_UID1
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/
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 A
AIL 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 ke
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
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
>
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 scri
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 alon
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]
> Sub
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 addi
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
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
Descr
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 lin
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
ROTECTED]>
> 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
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
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
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 connection
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 send
> 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
> 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 wit
40 matches
Mail list logo
