Ian Collins <[EMAIL PROTECTED]> wrote:
> William James wrote:
> > On 6/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> I have not seen a code quality lead for Linux, certainly not a large
> >> one.
> >>
> >> One tool which wans't mentioned was dbx' runtime checker, "rtc"
> >> which does quite a bit.
> >
> > (dbx) check -all
> > ...
> > dbx: warning: access checking is not available on x86
> >
> Upgrade to Studio 12:
>
> (dbx) check -all
> access checking - ON
> memuse checking - ON
>
> uname -a
> SunOS un-eng5 5.11 snv_62 i86pc i386 i86pc
If he was not interested in sending flames only, he could have checked Studio
12.
My impression is that the code quality in the Solaris kernel is definitely
better
than what you get from the Linux kernel. Let me give an example:
A few years ago, someone found that Solaris, Linux and FreeBSD could panic in
case that a CD/DVD with read errors (that result in wrong data read from the
media) because there was no range checking at all. FreeBSD did modify the
ISO-9660 fs driver, Solaris did add many checks and since the last hsfs putack
~ 3 weeks ago, all sensitive ISO-9660 FS meta data is checked for correctness.
Linux did not change anything and it is still simple to cause a Linux kernel
panic with a prepared CD/DVD.
If you look at the user space programs, things look different and there is no
simple way of selecting between good/bad. There are good _and_ bad
implementations in both camps. The code quality depends on the people. The fact
that regarding to user space pograms (in contrary to kernel code) Solaris is not
a definite quality leader is a result that Sun seems to be very proud of the
kernel but during the past 10 years forgot about the user space.
Any tool that helps to debug and analyze tools is a good idea. The fact that it
is available does not mean anything, you need to use it.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
