Re: Reflection and /proc

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Scott Lurndal writes:
> 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?

Yes, along with Alpha, PowerPC, MIPS, SPARC...

We might let lseek() be limited on 32-bit hardware, but the other
two are still important. I think FreeBSD made lseek() work right
on 32-bit hardware.

I just checked their web site. FreeBSD only supports lseek().
Since I know FreeBSD supports huge files and there is no mention of
a size-related error, it seems to me that they have a 64-bit lseek().

This makes sense; why should we change everything to lseek64()?
It is better to fix lseek(). Of course, Linux should still support
both lseek64() and llseek() for compatibility.

>>> 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 :-)

If you try to shoot down a feature that is supported by someone with
political power, you will hurt your career. (you've "got the scars")
Most people don't want to make enemies.

>>> 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.

Yes, but not a huge one. I do not suggest ignoring standards as a way
to force people to write Linux-specific code. That would be evil.
I don't even suggest creating duplicate functions to cause trouble.

I only suggest:

1. support foreign extensions (stuff from AIX, Solaris, Irix...)
2. support old Linux features
3. feel free to create useful features

>> Clone everybody, no matter who. When I wrote ps, I gave it an Irix
>> personality. Note the screwy "SZ:RSS" column below.
>
> How much time do you have :-)

Not much, but enough to do the job right. It took several months to
get a working program, and several more months to shake out the bugs.
Of course I wasn't working full-time on it.

Anything that didn't conflict went into the default personality. That
includes AIX format descriptors, 119 field names, HP-UX tree output,
obsolete BSD features like "ps t" (FreeBSD disowns it), etc.

$ ps -o "%u (everybody loves AIX) %U %p %c"
RUSER    (everybody loves AIX) USER       PID COMMAND
albert   (everybody loves AIX) albert    1987 ps
albert   (everybody loves AIX) albert    1009 bash
-
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