Re: Reflection and /proc

[slurn@griffin.engr.sgi.com (Scott Lurndal)]

In article <7bif65$acft3@fido.engr.sgi.com>, you write:
|> Scott Lurndal writes:
|> > In article <7bfoj4$a29oi@fido.engr.sgi.com>, you write:
|> 
|> >> Sure, we need standardized interfaces. No argument there!
|> >> We can also have Linux-specific interfaces. More is better.
|> > 
|> > More is not better.   Quality over quantity.
|> 
|> One need not choose between quality and quantity.
|> On 64-bit hardware, Linux could support:
|> 
|> lseek with no size restrictions (the right API, obviously)
|> llseek for SunOS 4 and libc 5 compatibility
|> lseek64 for standards compliance
|> 

Hmm..  Aren't we discussing Linux on intel ia32 here?

|> >>> This is just as bad as microsoft locking applications into NT.
|> >>
|> >> ...and Apple and Sun and SGI (yes, you!) and...
|> >
|> > No vendor that must show a profit will ever add things willy-nilly
|> > with no purpose other than "it is cool".  A business cannot survive
|> > with such an attitude.
|> 
|> How about "we have a big customer that wants this" or "we can get
|> an important software vendor to port if we add this"?

Over the years, we have learned the hard way that Nancy did 
coin at least one good phrase, "Just Say No!".

This quickly leads to kernel bloat.

|> 
|> > New features are always carefully thought out, clearly designed
|> > and appropriate for specific needs.  About half those which are
|> > proposed end up rejected.
|> 
|> I don't believe that for a moment. I'm sure politics play a huge
|> role here... but you'd better not talk about that.

Have you ever worked for a kernel vendor?  I've done kernels on
everything from mainframes through MPP boxes and without exception
every feature that has been put into those operating systems 
has gone through a rigorous design process (not all vendors
do this, but the older, established ones do);  I've got the scars
from the design reviews to prove it :-)

At a previous employer, for example,  three design
documents were required for major features:

	Requirements:
		What does this feature consist of (engineering)
		What need does this feature satisfy (marketing)
		What resources are required to produce this feature

	Conceptual:
		First level design of the feature.  Including overall
		subsystem descriptions.

	Detailed:
		Module/interface level description of feature.  Feature
		should be implementable by junior engineer from the
		information in the detailed design document.  Major 
		algorithms specified, etc. 

Each step in the process was accompanied by a design review 
meeting with representatives from the respective organizations
to ensure all were on the same page.   At each level, the feasibility
of the feature was also judged, and many never made it past the
conceptual phase. 

|> 

|> > The point of any operating system should be application capture.  Any
|> > proposed extension to the operating system must be justifiable in terms
|> > of application capture, or potentially ease of administration.
|> 
|> To capture applications, make porting _to_ the OS very easy.
|> (porting away is someone else's problem)

I see we have a basic difference in philosphy, here.

|> 
|> >>> Now, all commercial unices have proprietary extensions
|> >>
|> >> Linux should not be any different.
|> >
|> > Right.  But don't make them arbitrary and align them with
|> > existing interfaces and standards where they exist.  
|> > No matter whose existing interfaces or standards.
|> 
|> Clone everybody, no matter who. When I wrote ps, I gave it an Irix
|> personality. Note the screwy "SZ:RSS" column below.
|> t

How much time do you have :-)

|> $ PS_PERSONALITY=irix ps -l
|>   F S   UID   PID  PPID  C PRI  NI P    SZ:RSS  WCHAN  TTY          TIME CMD
|> 100 S   500  1009  1008  0  72   0 *   387:928  wait4  ttyp3    00:00:00 bash
|> 000 R   500  1489  1009 20  72   0 0   517:664  -      ttyp3    00:00:00 ps
|> 
|> I also reserved the -M for MAC info, just like Irix has.
|> (I would be very interested in examples of such output.)

I don't have secure irix running on my system, however a quick
perusal of ps.c shows that it is printed as the 'label' format
using a left justified string field (printing the result of the
mac_to_text() library function).

The label is printed in the first column when -M is
provided and -o is not provided.

scott lurndal
silicon graphics, inc.
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html