Messages in this thread | | | Subject | RE: Message codes (Re: [Announce] Linux-tiny project revival) | Date | Fri, 21 Sep 2007 15:12:09 -0700 | From | "Gross, Mark" <> |
| |
>-----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/
| |