Matt Mackall wrote:
Blech. Invoking the random pool machinery at oops time is moderately
safe, but not very shiny. Going through all the sprintf ugliness to
format it to an irrelevant UUID standard is not very shiny either. At
least refactor it so it's not duplicating code.
And I'd much rather
On Tue, 18 Dec 2007, Theodore Tso wrote:
>
> Well, Matt took over maintenance of the /dev/random driver, but my
> take on it is that code readability is more important that saving a
> few bytes of generated code or speed; the code paths are only executed
> once, so it's hardly a fast path.
Quit
Matt Mackall wrote:
Might as well leave out the null UUID, no sense in claiming to have
one when you don't. It's easy for a parser to cut on "^---["
one can't cut on that since that's also the start marker.
Yes it's possible to leave it out entirely, and thus have 2 different
terminators over
On Mon, Dec 17, 2007 at 10:58:54PM -0800, Arjan van de Ven wrote:
> Theodore Tso wrote:
>> On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
>>> which also gets bonus points for being totally unreadable, and thus 100%
>>> in the spirit of uuid's.
>> Heh. UUID's don't have to be read
On Tue, Dec 18, 2007 at 10:06:14AM -0800, Arjan van de Ven wrote:
> Linus Torvalds wrote:
> >
> >On Mon, 17 Dec 2007, Arjan van de Ven wrote:
> >>+char *get_boot_uuid(void)
> >>+{
> >>+ static char target[38];
> >>+ unsigned char *uuid;
> >>+
> >>+ if (sysctl_bootid[8] == 0)
> >>+ g
Linus Torvalds wrote:
On Mon, 17 Dec 2007, Arjan van de Ven wrote:
+char *get_boot_uuid(void)
+{
+ static char target[38];
+ unsigned char *uuid;
+
+ if (sysctl_bootid[8] == 0)
+ generate_random_uuid(sysctl_bootid);
+ /* sysctl_bootid is signed, to print we
On Mon, Dec 17, 2007 at 10:58:54PM -0800, Arjan van de Ven wrote:
> Theodore Tso wrote:
> >On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
> >>which also gets bonus points for being totally unreadable, and thus 100%
> >>in the spirit of uuid's.
> >
> >Heh. UUID's don't have to be
On Mon, Dec 17, 2007 at 01:36:31PM -0800, Arjan van de Ven wrote:
> On Mon, 17 Dec 2007 18:23:31 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > > The http://www.kerneloops.org website collects kernel oops and
> > > warning reports f
On Mon, 2007-12-17 at 21:31 -0500, Theodore Tso wrote:
> On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
> > which also gets bonus points for being totally unreadable, and thus 100%
> > in the spirit of uuid's.
>
> Heh. UUID's don't have to be readable; just universally unique.
Theodore Tso wrote:
On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
which also gets bonus points for being totally unreadable, and thus 100%
in the spirit of uuid's.
Heh. UUID's don't have to be readable; just universally unique. Code
on the other hand should be readable. :
On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
> which also gets bonus points for being totally unreadable, and thus 100%
> in the spirit of uuid's.
Heh. UUID's don't have to be readable; just universally unique. Code
on the other hand should be readable. :-)
If you want som
Linus Torvalds wrote:
On Mon, 17 Dec 2007, Arjan van de Ven wrote:
+char *get_boot_uuid(void)
+{
+ static char target[38];
+ unsigned char *uuid;
+
+ if (sysctl_bootid[8] == 0)
+ generate_random_uuid(sysctl_bootid);
+ /* sysctl_bootid is signed, to print we
On Mon, 17 Dec 2007, Arjan van de Ven wrote:
>
> +char *get_boot_uuid(void)
> +{
> + static char target[38];
> + unsigned char *uuid;
> +
> + if (sysctl_bootid[8] == 0)
> + generate_random_uuid(sysctl_bootid);
> + /* sysctl_bootid is signed, to print we need unsigned .
On Mon, 17 Dec 2007 15:26:46 -0800
"Tony Luck" <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 3:17 PM, Arjan van de Ven <[EMAIL PROTECTED]>
> wrote:
> >
> > Tony Luck wrote:
> > >> + static char target[80];
> > > ...
> > >> + sprintf(target,
> > >> "%02x%02x%02x%02x-%02x%02x-%02
On Dec 17, 2007 3:17 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> Tony Luck wrote:
> >> + static char target[80];
> > ...
> >> + sprintf(target,
> >> "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-"
> >> + "%02x%02x%02x%02x%02x%02x",
> >
> > [80] is
Tony Luck wrote:
+ static char target[80];
...
+ sprintf(target, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-"
+ "%02x%02x%02x%02x%02x%02x",
[80] is overkill ... [37] bytes should be enough (unless I went
cross-eyed counting the "%02x" :-)
%02x d
> + static char target[80];
...
> + sprintf(target, "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-"
> + "%02x%02x%02x%02x%02x%02x",
[80] is overkill ... [37] bytes should be enough (unless I went
cross-eyed counting the "%02x" :-)
-Tony
--
To unsubscribe
On Mon, Dec 17, 2007 at 01:36:31PM -0800, Arjan van de Ven wrote:
> Subject: [patch] terminate the oops printing with a defined string/uuid
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> Right now, it's hard for automated tools to determine when an oops has
> ended; there's no clear marker for t
On Mon, 17 Dec 2007 18:23:31 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > The http://www.kerneloops.org website collects kernel oops and
> > warning reports from various mailing lists and bugzillas; below is
> > a top 10 list of the oopses
Zach Brown wrote:
Report counts may be too high due to duplicate recognition of the very
same report.¹
this is true however it's .. a hard issue. It's really hard to
distinguish a duplicate report from
two reports of the same bug.
Can we hack some data in to oops output to help? Say a giant p
>> Report counts may be too high due to duplicate recognition of the very
>> same report.¹
>
> this is true however it's .. a hard issue. It's really hard to
> distinguish a duplicate report from
> two reports of the same bug.
Can we hack some data in to oops output to help? Say a giant per-boo
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> The http://www.kerneloops.org website collects kernel oops and warning
> reports from various mailing lists and bugzillas; below is a top 10
> list of the oopses collected in the last 7 days. (Reports prior to
> 2.6.23 have been omitted in collec
Stefan Richter wrote:
Jon Masters wrote:
On Sun, 2007-12-16 at 21:51 -0500, Dave Jones wrote:
On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
> Reports about tainted kernels have arguably less value. It would be
> good to hide such reports until a report of the same oops i
Jon Masters wrote:
> On Sun, 2007-12-16 at 21:51 -0500, Dave Jones wrote:
>> On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
>>
>> > Reports about tainted kernels have arguably less value. It would be
>> > good to hide such reports until a report of the same oops in an
>> > un
On Sun, 2007-12-16 at 21:51 -0500, Dave Jones wrote:
> On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
>
> > Reports about tainted kernels have arguably less value. It would be
> > good to hide such reports until a report of the same oops in an
> > untainted kernel was found.
On Sat, Dec 15, 2007 at 04:49:05PM +0100, Stefan Richter wrote:
> Reports about tainted kernels have arguably less value. It would be
> good to hide such reports until a report of the same oops in an
> untainted kernel was found.
I disagree with this. It's useful to have a "we've seen this
Arjan van de Ven wrote:
> Stefan Richter wrote:
>> Report counts may be too high due to duplicate recognition of the very
>> same report.
>
> this is true however it's .. a hard issue. It's really hard to
> distinguish a duplicate report from two reports of the same bug.
Would be nice though to t
Stefan Richter wrote:
Arjan van de Ven wrote:
The http://www.kerneloops.org website collects kernel oops and warning
reports from various mailing lists and bugzillas;
A few comments:
Report counts may be too high due to duplicate recognition of the very
same report.¹
this is true however it
Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and warning
> reports from various mailing lists and bugzillas;
A few comments:
Report counts may be too high due to duplicate recognition of the very
same report.¹
Reports against 2.6.X-rcY-mmZ are listed in th
Andrew Morton wrote:
On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
The http://www.kerneloops.org website collects kernel oops and warning
reports from various mailing lists and bugzillas
Well that would have been fun to write. Does it watch
https://lists.linu
On Dec 14, 2007 1:57 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > The http://www.kerneloops.org website collects kernel oops and warning
> > reports from various mailing lists and bugzillas
>
> Well that would ha
On Fri, 2007-12-14 at 10:46 -0800, Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and warning
> reports from various mailing lists and bugzillas; below is a top 10
> list of the oopses collected in the last 7 days. (Reports prior to 2.6.23
> have been omit
On Fri, 14 Dec 2007 10:46:36 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> The http://www.kerneloops.org website collects kernel oops and warning
> reports from various mailing lists and bugzillas
Well that would have been fun to write. Does it watch
https://lists.linux-foundation.org/mail
On Fri, Dec 14, 2007 at 10:46:36AM -0800, Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and warning
> reports from various mailing lists and bugzillas; below is a top 10
> list of the oopses collected in the last 7 days. (Reports prior to 2.6.23
> have
34 matches
Mail list logo
