Re: Reflection and /proc

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

In article <7bfoj4$a29oi@fido.engr.sgi.com>, you write:

|> > Feel free to design extensions - if they
|> > are satifactory to the other Unix vendors, they will eventually
|> > become adopted and standardized.   Please try to remember, however, that
|> > operating system interfaces are secondary to application portability;
|> > without applications you don't need an operating system, and without
|> > standardized interfaces, you won't capture the applications.
|> 
|> 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.

|> 
|> >>>>>> Solaris, HP/UX, Digital Unix, AIX, et. al. are too commercially
|> >>>>>> important for Linux to ignore.
|> >>>>>
|> >>>>> Sure... we should steal every feature they have, then add extensions.
|> >>>
|> >>> Ahh, embrace and extend - the microsoft mantra!
|> >>>
|> >>> (hopefully, you are not serious).
|> >>
|> >> Why not? Feaures and extensions are generally good.
|> >
|> > Then you lock applications into linux.
|> 
|> This is a Linux mailing list.

Big deal.  Linux should not make the same mistakes that others have.

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

New features are always carefully thought out, clearly designed
and appropriate for specific needs.  About half those which are
proposed end up rejected.

|> 
|> This is nothing compared to Richard Stallman using the GPL on libraries.
|> Friendly lock-in is much better than hostile lock-in via license.
|> 
|> > 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.

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


|> 
|> >> Backwards compatibility is an issue that should be taken seriously.
|> >> Linux libc 5 provided llseek. There is no conflict with a standard.
|> >> (in that case, commercial UNIX would typically ignore the standard)
|> >
|> > I don't agree with your parenthetical comment here.   Commercial unices
|> > _cannot_ ignore the standard.   The test suites which are used to determine
|> > if the implementation conforms with the standard are pretty good at
|> > testing these things (including the namespace pollution which the
|> > presence of an llseek prototype would cause).
|> 
|> Commercial UNIX vendors would ask for (and get) an exception.
|> I believe they have to list the violation somewhere, give a
|> reason, and claim to be working on a solution.

It is called a temporary waiver (permanent waivers are only granted
for specification errors).  It is, however, _temporary_, and getting
one granted requires concurrence from the kernel working group
(not necessarily easy).

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

|> >>>>> fputs() does not return a useful value. Both Digital UNIX and Solaris
|> >>>>> return the number of characters printed.
|> >>>
|> >>> non-standard and non-portable use of the return value for fputs.
|> >>
|> >> Another crap argument, same as the above. The C library should not
|> >> attempt to cause crashes and erroneous output.
|> >
|> > I'm sorry to have to disagree with your assessment of my argument.
|> >
|> > No matter which behavior fputs provides (returns 0 or returns n),
|> > half the applications which use fputs would break.   This was the
|> > reason that fputs() return value is specified by the standards as
|> > simply a non-negative number or the value represented by the EOF
|> > macro.
|> >
|> > I would rephrase your rebuttal as:
|> >
|> > 	The C Library cannot prevent a broken application from
|> >         causing crashes and erroneous output.
|> 
|> non-portable != broken
|> 
|> These applications are just fine, and glibc breaks them.

And if you change glibc, you'll break applications that currently
work just fine.   Damned if you do, damned if you don't. 

|> 
|> >>>>> SysV shared memory IPC is messed up. The struct ipc_perm members key
|> >>>>> and seq were renamed to __key and __seq This is incompatible with
|> >>>>> libc 5, AIX, and Solaris, Digital UNIX, etc. Some apps won't even
|> >>>>> compile anymore because glibc doesn't define SEMMSL and other SysV
|> >>>>> IPC related constants. (and they left the UID as a 16-bit value too)
|> >>>
|> >>> SEMMSL has never been a user-visible identifier on any version
|> >>> of unix, a great shortcoming by the way.
|> >>
|> >> So we could fix that great shortcoming. Actually, we have a
|> >> compatibility screw up here. Linux libc 5 had it.
|> >
|> > SEMMSL is not a constant, it is a tunable
|> > variable (except in linux where there are no tunable variables :=)
|> > and should be made available through a dynamic interface
|> > such as sysconf().
|> 
|> 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. 

|> 
|> >>> the key and seq members of the ipc_stat structure are private to
|> >>> the implementation
|> >>
|> >> Wrong: Solaris, Digital UNIX, AIX, and our own libc 5 support it.
|> >> It seems only glibc is hostile to developers.
|> >
|> > All unices include the members in the data structure.
|> 
|> Yes, and we should too.
|> 
|> > APPLICATIONS may not use either value, nor is there any
|> > assurance that either value will be passed to the applications
|> > through the IPC_STAT api.
|> >
|> > Note that portable applications may only rely on the
|> > uid, gid, cuid, cgid and mode fields in the ipc_perm
|> > data structure.
|> 
|> If "All unices include the members" then even portable applications
|> can use them. In any case, Linux should do the normal thing.

Just because all unices have "/usr/include/sys/proc.h" doesn't
give applications license to use the proc_t type or the fields 
therein. 

Linux did the correct thing in this case. 

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

|> 
|> > snprintf() is in the standards (XPG5).
|> >
|> > Equating bcopy() to kernel-private fields in a data structure
|> > is a poor analogy.   As a matter of fact, bcopy() is also a
|> > standard function (XPG4,XPG4.2,XPG5).
|> 
|> At one time they were not standard. Support was common, so they
|> were standardized. We should expect common features to become
|> standard, including the seq and key members of ipc_perm.

Hey, I participated in standards for ten years.  I can guarantee
you that seq and key members of ipc_perm will _NEVER_ become
standard;  they are artifacts of the implementation and absolutely
unusable by applications.   Any application which did use the 
fields would not run correctly on many architectures as the
algorithm to compute the id from the key & optional seq fields
differs by implementation.


|> 
|> >> I don't want a compliance tester.
|> >
|> > And I guess you aren't charged with developing portable
|> > applications either. 
|> 
|> I include <linux/*.h> and use /proc/* whenever possible.

It is pretty clear that this limits the scope of your applications
soley to linux.   Your choice.

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