Re: Reflection and /proc

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

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

>>> 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"?

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

>>> In a perfect world,
>>> the same API would work on all operating systems.
>>
>> Option 1: clone the Linux API as needed (FreeBSD and SCO do this)
>
> Option 1:  clone the WIN32 api (WINE does this)
> Option 2:  port WINE to your proprietary platform.

It is perfectly normal for Microsoft to give us such a choice.
I don't see anything unusual about it.

>> Option 2: port Linux to your hardware (workstation vendors do this)
>
> 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)

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

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

>> So SEMMSL is a constant, and we ought to provide it while we can.
>> Should a time come when it is no longer a constant, we do this:
>>
>> #define SEMMSL (sysconf(WHATEVER))
>
> Disagree.  Do it right the first time.

As the above? That would be OK, but not quite as compatible.
It would let today's binaries work well into the future though,
so I would be happy with it.

>>> First of all, a feature has to be worth supporting, and providing
>>> the seq and key values in the ipc_perm structure is _not_ worth
>>> supporting; neither of them is of any use to an application.
>>
>> Obviously they _are_ of use, because some apps broke.
>
> Name the apps.

Check www.dejanews.com yourself. There were several apps that broke.
Start with comp.os.linux.development (dead group) and the two new
groups in comp.os.linux.development.* .
-
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