Re: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Oleg Verych 
On Fri, Sep 21, 2007 at 04:15:39PM -0500, Rob Landley wrote:
[]
> > >Not all, but critical info, that must exist in human-readable form of
> > >course.
> >
> > I disagree.  For a production product the you want minimal information
> > to reduce the communication bandwidth required between the remote
> > customer and the support organization.
> >
> > In fact there is a good argument that you don't what the remote customer
> > to know enough to start guessing.
> 
> Don't use Linux then.  Open source is a horrible fit for the way you think.
> 
> I'm sympathetic to "shrink the binary size" arguments.  I'm not really 
> sympathic to "keep the customer in the dark intentionally" arguments, whether 
> the justification is "because they're stupid", "to increase dependency on our 
> support staff", or any other reason.

{1} 

> > >Seriously. When in the Windows there are only messages like:
> > >
> > >"Error (Code:0x2012)".
> >
> > Now it's been ~8 years since I did any serious windows work, but if I
> > recall correctly ALL THE FRICKING TIME!!! When was the last time you've
> > seen a bug check on windows?  This is about all you get.
> 
> I believe he was holding it up as a bad example, and definitely not something 
> we want to emulate.

I tried to show, that keeping users in compete information vacuum is a
bad thing. Even without sources, _configuration_ makes another area of
mis-working and bugs, usually addressed by reinstalling.

That may be bad example, because here talk is about developers and
testers, who are not just ordinary users. And by applying Torvalds's Law,
all users are such in some degree. That's why {1} in your reply, Rob,
makes perfect sense.

If Mark have a bad experience with lusers only, then i just can say: what
a pity! AFAIK nobody can read somebody's plain-bin OOP output.

Anyway, anything must be opted by config options, even schedulers. But
maintenance and flame wars rule otherwise :).

What i can propose is form of binary-only "printk", where all info:
diagnostic, error, bug, statistics messages (in not debugging
environment, of course), is just fed right to output buffer (see,
pa, no kmallocs). Info itself must have structured content, that makes it
easy to extract and locate human-readable representation of both message
and data.

This doesn't address loglevels, though.

Implementation (seems) as easy as feeding output to `od` to have
unambiguous form of various troublesome bytes, like "0x00" and "0x0A",

Structuring, who is printing, i.e. arch code, fs, driver whatever, must be
agreed:

*  Profiles[0]: originator's ID of a message is a byte (or word, or double word)
   0x01 - arch, 0x02 - fs, 0x03 - net, 0x04 - hw drivers, etc.

*  Data itself can be sent in form of [0]

[0] Banana -- extendable protocol for sending and receiving s-expressions

http://twistedmatrix.com/projects/core/documentation/specifications/banana.html

and having shell script with functions, that have names that correspond
to actual structured content:
_*_
[EMAIL PROTECTED]:/tmp$ sh banana.sh < banana.c >bb
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07080'
start
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07081'
ti_startup - product , num configurations 0, configuration value 0
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07082'
not reached
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07081 777 7 8'
ti_startup - product 0x0309, num configurations 7, configuration value 8
[EMAIL PROTECTED]:/tmp$

_(banana.c and banana.sh can be found in the ftp /upload on my server)_

>From file linux/drivers/usb/serial/ti_usb*c with

[...]
dbg("%s - product 0x%4X, num configurations %d, configuration value %d",
__FUNCTION__, le16_to_cpu(dev->descriptor.idProduct),
dev->descriptor.bNumConfigurations,
dev->actconfig->desc.bConfigurationValue);
[...]


lets tacke one particular function (transformed a little bit):
_*_

#include 

#define dbg printf
#define ti_startup(foo) main (int argc, char **argv)
#define dev_descriptor_idProduct3
#define dev_descriptor_bNumConfigurations   4
#define dev_actconfig_desc_bConfigurationValue  5

/* declaration */
int ti_startup(void);

/* implementation */
int ti_startup(void)
{
dbg("start\n");

return dbg("%s - product %#.4x, num configurations %d, "
"configuration value %d\n",
__FUNCTION__, dev_descriptor_idProduct,
dev_descriptor_bNumConfigurations,
dev_actconfig_desc_bConfigurationValue);

/* bla bla */
dbg("not reached\n");
}
_*_

* Process this file with this script: *

_*_

# just as an example
USB_SERIAL_ID=07
TI_USB_ID=08
__FILE__="ti_usb_3410_5052.c" # possible
i=0

sed -n '
# finding function body
/^[[:alpha:]]/{
# found, print it for __FUNCTION__ keyword
s_[^ ]* *\([^ (]*\).*[^;]$_\1_p;
t_func ; b ;
# walking inside of a function
:_func;
# load

RE: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


>-Original Message-
>From: Joe Perches [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 21, 2007 3:33 PM
>To: Gross, Mark
>Cc: Rob Landley; Oleg Verych; Alexey Dobriyan; Michael Opdenacker;
linux-
>[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>Subject: RE: Message codes (Re: [Announce] Linux-tiny project revival)
>
>On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
>> Use compiler tricks to remove ALL the static printk string from
>> the kernel and replace the printk with something that outputs a
>> decimal index followed by tuples, of zero to N, hex-strings on
>
>> I proposed a mechanism for keeping all the printk data and saving
space
>> buy doing some table based compressions that has the side effect of
>> making the syslog not human readable.  You proposed a mechanism for
>> no-oping out complete log-levels.
>
>How about compiler tricks to compress the static printk strings?
>These could be expanded at runtime to use as the format.

You would have to hold the text table (compressed) in memory to do this
at run time.  That would still be pretty large hunk of memory.  

>
>Timothy Miller suggested something similar awhile ago.
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Joe Perches 
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
> Use compiler tricks to remove ALL the static printk string from
> the kernel and replace the printk with something that outputs a
> decimal index followed by tuples, of zero to N, hex-strings on

> I proposed a mechanism for keeping all the printk data and saving space
> buy doing some table based compressions that has the side effect of
> making the syslog not human readable.  You proposed a mechanism for
> no-oping out complete log-levels.   

How about compiler tricks to compress the static printk strings?
These could be expanded at runtime to use as the format.

Timothy Miller suggested something similar awhile ago.

-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


>-Original Message-
>From: Rob Landley [mailto:[EMAIL PROTECTED]
>Sent: Friday, September 21, 2007 2:16 PM
>To: Gross, Mark
>Cc: Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux-
>[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>Subject: Re: Message codes (Re: [Announce] Linux-tiny project revival)
>
>On Friday 21 September 2007 9:18:40 am Gross, Mark wrote:
>> >-Original Message-
>> >From: Oleg Verych [mailto:[EMAIL PROTECTED]
>> >Sent: Thursday, September 20, 2007 5:58 PM
>> >To: Gross, Mark
>> >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
>> >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>> >Subject: Message codes (Re: [Announce] Linux-tiny project revival)
>> >
>> >* Thu, 20 Sep 2007 15:15:47 -0700
>> >* X-MimeOLE: Produced By Microsoft Exchange V6.5
>> >[]
>> >
>> >>>*Shrug*.
>> >>>
>> >>>My problem is that switching off printk is the single biggest
bloat
>> >>
>> >> cutter
>> >>
>> >>>in
>> >>>the kernel, yet it makes the resulting system very hard to
support.
>>
>> It
>>
>> >>>combines a big upside with a big downside, and I'd like something
in
>> >>>between.
>> >>
>> >> What about getting even more hard core?
>> >>
>> >> Use compiler tricks to remove ALL the static printk string from
the
>> >> kernel and replace the printk with something that outputs an
decimal
>> >> index followed by tuples, of zero to N, hex-strings on a single
line.
>> >
>> >Not all, but critical info, that must exist in human-readable form
of
>> >course.
>>
>> I disagree.  For a production product the you want minimal
information
>> to reduce the communication bandwidth required between the remote
>> customer and the support organization.
>>
>> In fact there is a good argument that you don't what the remote
customer
>> to know enough to start guessing.
>
>Don't use Linux then.  Open source is a horrible fit for the way you
think.

I'll do what I like, thank you.  I'll continue to use Linux, I think
it's a fine fit for the way *I* think.

>
>I'm sympathetic to "shrink the binary size" arguments.  I'm not really
>sympathic to "keep the customer in the dark intentionally" arguments,
>whether
>the justification is "because they're stupid", "to increase dependency
on
>our
>support staff", or any other reason.

You are now talking religion at this point.  Do you have a technical or
even experience based point to make?  

I have experience that has shown that providing too much information in
a production product can is confusing, harmful and costly when dealing
with consumers.  Your opinions won't change that.

I proposed a mechanism for keeping all the printk data and saving space
buy doing some table based compressions that has the side effect of
making the syslog not human readable.  You proposed a mechanism for
no-oping out complete log-levels.   

Which way hides more from the user?  No-oping the log-levels is the
easier to implement.


>
>> >Seriously. When in the Windows there are only messages like:
>> >
>> >"Error (Code:0x2012)".
>>
>> Now it's been ~8 years since I did any serious windows work, but if I
>> recall correctly ALL THE FRICKING TIME!!! When was the last time
you've
>> seen a bug check on windows?  This is about all you get.
>
>I believe he was holding it up as a bad example, and definitely not
>something
>we want to emulate.

There is a time and place for many things.  Even error codes. 

--mgross
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Rob Landley 
On Friday 21 September 2007 9:18:40 am Gross, Mark wrote:
> >-Original Message-
> >From: Oleg Verych [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, September 20, 2007 5:58 PM
> >To: Gross, Mark
> >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
> >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
> >Subject: Message codes (Re: [Announce] Linux-tiny project revival)
> >
> >* Thu, 20 Sep 2007 15:15:47 -0700
> >* X-MimeOLE: Produced By Microsoft Exchange V6.5
> >[]
> >
> >>>*Shrug*.
> >>>
> >>>My problem is that switching off printk is the single biggest bloat
> >>
> >> cutter
> >>
> >>>in
> >>>the kernel, yet it makes the resulting system very hard to support.
>
> It
>
> >>>combines a big upside with a big downside, and I'd like something in
> >>>between.
> >>
> >> What about getting even more hard core?
> >>
> >> Use compiler tricks to remove ALL the static printk string from the
> >> kernel and replace the printk with something that outputs an decimal
> >> index followed by tuples, of zero to N, hex-strings on a single line.
> >
> >Not all, but critical info, that must exist in human-readable form of
> >course.
>
> I disagree.  For a production product the you want minimal information
> to reduce the communication bandwidth required between the remote
> customer and the support organization.
>
> In fact there is a good argument that you don't what the remote customer
> to know enough to start guessing.

Don't use Linux then.  Open source is a horrible fit for the way you think.

I'm sympathetic to "shrink the binary size" arguments.  I'm not really 
sympathic to "keep the customer in the dark intentionally" arguments, whether 
the justification is "because they're stupid", "to increase dependency on our 
support staff", or any other reason.

> >Seriously. When in the Windows there are only messages like:
> >
> >"Error (Code:0x2012)".
>
> Now it's been ~8 years since I did any serious windows work, but if I
> recall correctly ALL THE FRICKING TIME!!! When was the last time you've
> seen a bug check on windows?  This is about all you get.

I believe he was holding it up as a bad example, and definitely not something 
we want to emulate.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


>-Original Message-
>From: Oleg Verych [mailto:[EMAIL PROTECTED]
>Sent: Thursday, September 20, 2007 5:58 PM
>To: Gross, Mark
>Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
>[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>Subject: Message codes (Re: [Announce] Linux-tiny project revival)
>
>* Thu, 20 Sep 2007 15:15:47 -0700
>* X-MimeOLE: Produced By Microsoft Exchange V6.5
>[]
>>>*Shrug*.
>>>
>>>My problem is that switching off printk is the single biggest bloat
>> cutter
>>>in
>>>the kernel, yet it makes the resulting system very hard to support.
It
>>>combines a big upside with a big downside, and I'd like something in
>>>between.
>>
>> What about getting even more hard core?
>>
>> Use compiler tricks to remove ALL the static printk string from the
>> kernel and replace the printk with something that outputs an decimal
>> index followed by tuples, of zero to N, hex-strings on a single line.
>
>Not all, but critical info, that must exist in human-readable form of
>course.

I disagree.  For a production product the you want minimal information
to reduce the communication bandwidth required between the remote
customer and the support organization.

In fact there is a good argument that you don't what the remote customer
to know enough to start guessing.  In the support stage of a products
life cycle you really don't want guessing or fudging of information
based on guessing.  Keeping the output cryptic and short will avoid
these things.  (That really does happen and it cost a lot in support
engineering time)

>
>> Then have the syslogd or some other utility take this cryptic output
and
>> convolve it with a table (created at compile time) to re-create what
>> would have been dumped to the sys-log ring buffer.  This way you
strip
>> out most of the static text from the kernel and yet can still
re-create
>> the kernlog output.
>>
>> At least as a post processing operation
>
>Sure, but a little problem is, that many kernel developers do C
(mostly)
>and Perl (occasionally), i.e. very few do non-trivial userspace (even
>userspace do too much C and Perl sometimes [:
>)
>

Oh poo.  Kernel programmers can use user mode tools and write them too,
and I *know* even I could write such a post processing program to take a
somewhat compressed and cryptic output and generate what would have been
created in the syslog used.  (in python)

>> Is this an old idea?  I'm guessing this has been at least proposed
>> before
>
>Seriously. When in the Windows there are only messages like:
>
>"Error (Code:0x2012)".

Now it's been ~8 years since I did any serious windows work, but if I
recall correctly ALL THE FRICKING TIME!!! When was the last time you've
seen a bug check on windows?  This is about all you get.

>
>In the Linux... well, embedded targets, this can be turned in a very
>efficient thing by means of userspace. On other setups this can be nice
>and pleasant one, with yet another L10N project, recently promoted by
>README translations. But,,, see problem above.
>

>From you comments I'm not sure you are for or against this idea.

--mgross
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


-Original Message-
From: Oleg Verych [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 20, 2007 5:58 PM
To: Gross, Mark
Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
Subject: Message codes (Re: [Announce] Linux-tiny project revival)

* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
*Shrug*.

My problem is that switching off printk is the single biggest bloat
 cutter
in
the kernel, yet it makes the resulting system very hard to support.
It
combines a big upside with a big downside, and I'd like something in
between.

 What about getting even more hard core?

 Use compiler tricks to remove ALL the static printk string from the
 kernel and replace the printk with something that outputs an decimal
 index followed by tuples, of zero to N, hex-strings on a single line.

Not all, but critical info, that must exist in human-readable form of
course.

I disagree.  For a production product the you want minimal information
to reduce the communication bandwidth required between the remote
customer and the support organization.

In fact there is a good argument that you don't what the remote customer
to know enough to start guessing.  In the support stage of a products
life cycle you really don't want guessing or fudging of information
based on guessing.  Keeping the output cryptic and short will avoid
these things.  (That really does happen and it cost a lot in support
engineering time)


 Then have the syslogd or some other utility take this cryptic output
and
 convolve it with a table (created at compile time) to re-create what
 would have been dumped to the sys-log ring buffer.  This way you
strip
 out most of the static text from the kernel and yet can still
re-create
 the kernlog output.

 At least as a post processing operation

Sure, but a little problem is, that many kernel developers do C
(mostly)
and Perl (occasionally), i.e. very few do non-trivial userspace (even
userspace do too much C and Perl sometimes [:
http://thread.gmane.org/gmane.comp.lib.glibc.alpha/12739)


Oh poo.  Kernel programmers can use user mode tools and write them too,
and I *know* even I could write such a post processing program to take a
somewhat compressed and cryptic output and generate what would have been
created in the syslog used.  (in python)

 Is this an old idea?  I'm guessing this has been at least proposed
 before

Seriously. When in the Windows there are only messages like:

Error (Code:0x2012).

Now it's been ~8 years since I did any serious windows work, but if I
recall correctly ALL THE FRICKING TIME!!! When was the last time you've
seen a bug check on windows?  This is about all you get.


In the Linux... well, embedded targets, this can be turned in a very
efficient thing by means of userspace. On other setups this can be nice
and pleasant one, with yet another L10N project, recently promoted by
README translations. But,,, see problem above.


From you comments I'm not sure you are for or against this idea.

--mgross
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Rob Landley 
On Friday 21 September 2007 9:18:40 am Gross, Mark wrote:
 -Original Message-
 From: Oleg Verych [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 20, 2007 5:58 PM
 To: Gross, Mark
 Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
 [EMAIL PROTECTED]; CE Linux Developers List; linux kernel
 Subject: Message codes (Re: [Announce] Linux-tiny project revival)
 
 * Thu, 20 Sep 2007 15:15:47 -0700
 * X-MimeOLE: Produced By Microsoft Exchange V6.5
 []
 
 *Shrug*.
 
 My problem is that switching off printk is the single biggest bloat
 
  cutter
 
 in
 the kernel, yet it makes the resulting system very hard to support.

 It

 combines a big upside with a big downside, and I'd like something in
 between.
 
  What about getting even more hard core?
 
  Use compiler tricks to remove ALL the static printk string from the
  kernel and replace the printk with something that outputs an decimal
  index followed by tuples, of zero to N, hex-strings on a single line.
 
 Not all, but critical info, that must exist in human-readable form of
 course.

 I disagree.  For a production product the you want minimal information
 to reduce the communication bandwidth required between the remote
 customer and the support organization.

 In fact there is a good argument that you don't what the remote customer
 to know enough to start guessing.

Don't use Linux then.  Open source is a horrible fit for the way you think.

I'm sympathetic to shrink the binary size arguments.  I'm not really 
sympathic to keep the customer in the dark intentionally arguments, whether 
the justification is because they're stupid, to increase dependency on our 
support staff, or any other reason.

 Seriously. When in the Windows there are only messages like:
 
 Error (Code:0x2012).

 Now it's been ~8 years since I did any serious windows work, but if I
 recall correctly ALL THE FRICKING TIME!!! When was the last time you've
 seen a bug check on windows?  This is about all you get.

I believe he was holding it up as a bad example, and definitely not something 
we want to emulate.

Rob
-- 
One of my most productive days was throwing away 1000 lines of code.
  - Ken Thompson.
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


-Original Message-
From: Rob Landley [mailto:[EMAIL PROTECTED]
Sent: Friday, September 21, 2007 2:16 PM
To: Gross, Mark
Cc: Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux-
[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
Subject: Re: Message codes (Re: [Announce] Linux-tiny project revival)

On Friday 21 September 2007 9:18:40 am Gross, Mark wrote:
 -Original Message-
 From: Oleg Verych [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 20, 2007 5:58 PM
 To: Gross, Mark
 Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
 [EMAIL PROTECTED]; CE Linux Developers List; linux kernel
 Subject: Message codes (Re: [Announce] Linux-tiny project revival)
 
 * Thu, 20 Sep 2007 15:15:47 -0700
 * X-MimeOLE: Produced By Microsoft Exchange V6.5
 []
 
 *Shrug*.
 
 My problem is that switching off printk is the single biggest
bloat
 
  cutter
 
 in
 the kernel, yet it makes the resulting system very hard to
support.

 It

 combines a big upside with a big downside, and I'd like something
in
 between.
 
  What about getting even more hard core?
 
  Use compiler tricks to remove ALL the static printk string from
the
  kernel and replace the printk with something that outputs an
decimal
  index followed by tuples, of zero to N, hex-strings on a single
line.
 
 Not all, but critical info, that must exist in human-readable form
of
 course.

 I disagree.  For a production product the you want minimal
information
 to reduce the communication bandwidth required between the remote
 customer and the support organization.

 In fact there is a good argument that you don't what the remote
customer
 to know enough to start guessing.

Don't use Linux then.  Open source is a horrible fit for the way you
think.

I'll do what I like, thank you.  I'll continue to use Linux, I think
it's a fine fit for the way *I* think.


I'm sympathetic to shrink the binary size arguments.  I'm not really
sympathic to keep the customer in the dark intentionally arguments,
whether
the justification is because they're stupid, to increase dependency
on
our
support staff, or any other reason.

You are now talking religion at this point.  Do you have a technical or
even experience based point to make?  

I have experience that has shown that providing too much information in
a production product can is confusing, harmful and costly when dealing
with consumers.  Your opinions won't change that.

I proposed a mechanism for keeping all the printk data and saving space
buy doing some table based compressions that has the side effect of
making the syslog not human readable.  You proposed a mechanism for
no-oping out complete log-levels.   

Which way hides more from the user?  No-oping the log-levels is the
easier to implement.



 Seriously. When in the Windows there are only messages like:
 
 Error (Code:0x2012).

 Now it's been ~8 years since I did any serious windows work, but if I
 recall correctly ALL THE FRICKING TIME!!! When was the last time
you've
 seen a bug check on windows?  This is about all you get.

I believe he was holding it up as a bad example, and definitely not
something
we want to emulate.

There is a time and place for many things.  Even error codes. 

--mgross
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Joe Perches 
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
 Use compiler tricks to remove ALL the static printk string from
 the kernel and replace the printk with something that outputs a
 decimal index followed by tuples, of zero to N, hex-strings on

 I proposed a mechanism for keeping all the printk data and saving space
 buy doing some table based compressions that has the side effect of
 making the syslog not human readable.  You proposed a mechanism for
 no-oping out complete log-levels.   

How about compiler tricks to compress the static printk strings?
These could be expanded at runtime to use as the format.

Timothy Miller suggested something similar awhile ago.

-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Gross, Mark 


-Original Message-
From: Joe Perches [mailto:[EMAIL PROTECTED]
Sent: Friday, September 21, 2007 3:33 PM
To: Gross, Mark
Cc: Rob Landley; Oleg Verych; Alexey Dobriyan; Michael Opdenacker;
linux-
[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
Subject: RE: Message codes (Re: [Announce] Linux-tiny project revival)

On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
 Use compiler tricks to remove ALL the static printk string from
 the kernel and replace the printk with something that outputs a
 decimal index followed by tuples, of zero to N, hex-strings on

 I proposed a mechanism for keeping all the printk data and saving
space
 buy doing some table based compressions that has the side effect of
 making the syslog not human readable.  You proposed a mechanism for
 no-oping out complete log-levels.

How about compiler tricks to compress the static printk strings?
These could be expanded at runtime to use as the format.

You would have to hold the text table (compressed) in memory to do this
at run time.  That would still be pretty large hunk of memory.  


Timothy Miller suggested something similar awhile ago.
-
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: Message codes (Re: [Announce] Linux-tiny project revival)

2007-09-21 Thread Oleg Verych 
On Fri, Sep 21, 2007 at 04:15:39PM -0500, Rob Landley wrote:
[]
  Not all, but critical info, that must exist in human-readable form of
  course.
 
  I disagree.  For a production product the you want minimal information
  to reduce the communication bandwidth required between the remote
  customer and the support organization.
 
  In fact there is a good argument that you don't what the remote customer
  to know enough to start guessing.
 
 Don't use Linux then.  Open source is a horrible fit for the way you think.
 
 I'm sympathetic to shrink the binary size arguments.  I'm not really 
 sympathic to keep the customer in the dark intentionally arguments, whether 
 the justification is because they're stupid, to increase dependency on our 
 support staff, or any other reason.

{1} 

  Seriously. When in the Windows there are only messages like:
  
  Error (Code:0x2012).
 
  Now it's been ~8 years since I did any serious windows work, but if I
  recall correctly ALL THE FRICKING TIME!!! When was the last time you've
  seen a bug check on windows?  This is about all you get.
 
 I believe he was holding it up as a bad example, and definitely not something 
 we want to emulate.

I tried to show, that keeping users in compete information vacuum is a
bad thing. Even without sources, _configuration_ makes another area of
mis-working and bugs, usually addressed by reinstalling.

That may be bad example, because here talk is about developers and
testers, who are not just ordinary users. And by applying Torvalds's Law,
all users are such in some degree. That's why {1} in your reply, Rob,
makes perfect sense.

If Mark have a bad experience with lusers only, then i just can say: what
a pity! AFAIK nobody can read somebody's plain-bin OOP output.

Anyway, anything must be opted by config options, even schedulers. But
maintenance and flame wars rule otherwise :).

What i can propose is form of binary-only printk, where all info:
diagnostic, error, bug, statistics messages (in not debugging
environment, of course), is just fed right to output buffer (see,
pa, no kmallocs). Info itself must have structured content, that makes it
easy to extract and locate human-readable representation of both message
and data.

This doesn't address loglevels, though.

Implementation (seems) as easy as feeding output to `od` to have
unambiguous form of various troublesome bytes, like 0x00 and 0x0A,

Structuring, who is printing, i.e. arch code, fs, driver whatever, must be
agreed:

*  Profiles[0]: originator's ID of a message is a byte (or word, or double word)
   0x01 - arch, 0x02 - fs, 0x03 - net, 0x04 - hw drivers, etc.

*  Data itself can be sent in form of [0]

[0] Banana -- extendable protocol for sending and receiving s-expressions

http://twistedmatrix.com/projects/core/documentation/specifications/banana.html

and having shell script with functions, that have names that correspond
to actual structured content:
_*_
[EMAIL PROTECTED]:/tmp$ sh banana.sh  banana.c bb
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07080'
start
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07081'
ti_startup - product , num configurations 0, configuration value 0
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07082'
not reached
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$ sh -c '. ./bb ; _07081 777 7 8'
ti_startup - product 0x0309, num configurations 7, configuration value 8
[EMAIL PROTECTED]:/tmp$

_(banana.c and banana.sh can be found in the ftp /upload on my server)_

From file linux/drivers/usb/serial/ti_usb*c with

[...]
dbg(%s - product 0x%4X, num configurations %d, configuration value %d,
__FUNCTION__, le16_to_cpu(dev-descriptor.idProduct),
dev-descriptor.bNumConfigurations,
dev-actconfig-desc.bConfigurationValue);
[...]


lets tacke one particular function (transformed a little bit):
_*_

#include stdio.h

#define dbg printf
#define ti_startup(foo) main (int argc, char **argv)
#define dev_descriptor_idProduct3
#define dev_descriptor_bNumConfigurations   4
#define dev_actconfig_desc_bConfigurationValue  5

/* declaration */
int ti_startup(void);

/* implementation */
int ti_startup(void)
{
dbg(start\n);

return dbg(%s - product %#.4x, num configurations %d, 
configuration value %d\n,
__FUNCTION__, dev_descriptor_idProduct,
dev_descriptor_bNumConfigurations,
dev_actconfig_desc_bConfigurationValue);

/* bla bla */
dbg(not reached\n);
}
_*_

* Process this file with this script: *

_*_

# just as an example
USB_SERIAL_ID=07
TI_USB_ID=08
__FILE__=ti_usb_3410_5052.c # possible
i=0

sed -n '
# finding function body
/^[[:alpha:]]/{
# found, print it for __FUNCTION__ keyword
s_[^ ]* *\([^ (]*\).*[^;]$_\1_p;
t_func ; b ;
# walking inside of a function
:_func;
# load next string from the input
n;
# while not the end of a