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

["Gross, Mark" <mark.gross@intel.com>]

>-----Original Message-----
>From: Rob Landley [mailto:rob@landley.net]
>Sent: Friday, September 21, 2007 2:16 PM
>To: Gross, Mark
>Cc: Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux-
>tiny@selenic.com; 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:olecom@flower.upol.cz]
>> >Sent: Thursday, September 20, 2007 5:58 PM
>> >To: Gross, Mark
>> >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
>> >tiny@selenic.com; 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:0x00002012)".
>>
>> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/