Re: Reflection and /proc

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

In article <7bf7cn$9vcd3@fido.engr.sgi.com>, "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
|> Scott Lurndal writes:
|> > Albert D. Cahalan <acahalan@cs.uml.edu> wrote :
|> >>> Charles Cazabon writes:
|> >>>> Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
|> 
|> >>>> SCO and *BSD doesn't mean 'everybody' -- Linux cannot expect to
|> >>>> flagrantly violate existing practice and have the rest of the
|> >>>> Unixen follow suit.
|> >>> 
|> >>> Oh please. Do you think Sun asks Compaq for permission to write
|> >>> something useful? Do you think IBM waits for The Open Group?
|> > 
|> > As a matter of fact, IBM is a very strong voice in the Open Group,
|> > and while they don't necessarily wait for them, they don't 
|> > violate existing practice either [well, there was the time they
|> 
|> So "they don't [...] wait". Linux hackers should not wait either.

You didn't quote the rest of the sentence:  They don't violate
existing practice either.  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.

|> 
|> >>>> 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 just as bad
as microsoft locking applications into NT.    In a perfect world, 
the same API would work on all operating systems.  As this is
a less  than perfect world, only a subset of such an API is available
on many different (internally) operating systems, and that is 
the POSIX API (and while many decry the POSIX API provided by 
microsoft NT, it _is_ usable for some significant applications).

|> 
|> >>> ---------------- List of glibc misfeatures: ---------------
|> >>> 
|> >>> llseek() does not have a prototype; this intentional bug destroyed some
|> >>> people's filesystems when fsck ran 
|> >
|> > non-standard, non-portable function.  Subsumed by lseek64.  Should
|> > be deprecated when LFS support added.
|> 
|> CAn you read? Removal destroyed filesystems. That is, removal caused the
|> loss of gigabytes of data while users were trying to fix minor errors.
|> This is seriously bad.

My reading skills are pretty good, in my opinion.   The correct fix 
for this bug would have been to convert the broken code to use the 
non-deprecated interface, not to promulgate a dead interface forwards.

Bugs happen.  Data gets lost.  The bug gets fixed and life goes on.
Hopefully, people who care about their data do back it up.

Backwards compatability doesn't seem to be a highly regarded feature
in linux - while a commercial unix cannot survive without it.

|> 
|> The "non-standard, non-portable function" argument is crap. Nothing says
|> that we may only support lseek64. We can have both. Anyway, Sun has llseek.

Sun also has lseek64, and recommends it for new applications.  

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

Now, all commercial unices have proprietary extensions (which many consider
to be the downfall of unix vis-a-vis NT; I won't go there except to say
that I disagree), however, the presence of a proprietary extension
is not precluded by the standards, as they are outside the purvue 
of the standard.

It bears repeating that the standards (POSIX and XPG as examples) were
never designed to make all implementations identical, it was to provide
for portable applications - allowing a common subset of the various proprietary
API's applications could be assured would always be present and 
would always function as prescribed.

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

|> 
|> > Standard explicitly doesn't specify the return value of fputs
|> > because the two unix universes handled it differently. 
|> 
|> What two? BSD is not UNIX. Anyone who wants BSD should get the real thing.
|> It would be incredibly stupid to clone BSD, since BSD is already free.

I'm sure that you would find many who would argue with you 
vis-a-vis BSD != Unix.    While I am a dyed-in-the-wool 
System V advocate, I would argue that BSD is just as much
Unix as System V is (as both derived from the sixth and 
seventh editions of unix) and both have very desirable 
feature sets. 

As it happens, the standards bodies were made up of Unix
system vendors some of whose systems were derived from the
BSD branch of unix, and others whose systems were derived
from the System V branch.  Both camps had large numbers 
of users, systems and applications.  The standards bodies, 
therefore, after much argument and gnashing of teeth, 
correctly decided that where the differences between the
implementation were significant, that both behaviors 
would be allowed and neither standardized.   This allowed
existing applications from either branch to continue to 
work, while new applications would no longer rely on the
undefined behavior.

(the signal() system call is a notable exception to the 
above paragraph, although note the bsd_signal interface
in XPG).

|> 
|> > Therefore, no portable software can make use of the return value
|> > of fputs, ipso facto, the return value _is_ useless, and may as
|> > well be void.
|> 
|> So you see no reason why someone would want to port from Solaris
|> or Digital UNIX to Linux? Do you want to make it difficult?
|> 
|> >>> 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().


|> 
|> > 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.   None of
the unices provided them for applications (they are actually
there because the old ipcs command read the ipc_perm structure
through /dev/kmem and needed the seq value to find the xxx_ds
structure in the kernel).

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. 

|> 
|> > and may not be used by portable applications.
|> 
|> Here you go again... This is not a reason why we shouldn't support
|> the feature. Shall we remove snprintf() and bcopy()? I think not!

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.

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

|> 
|> >>> Almost everything must be compiled with -D_GNU_SOURCE, including
|> >>> non-GNU software. The namespace logic is backwards; one should
|> >>> specify POSIX to get a plain, bland, vanilla (nearly useless) namespace. 

|> 
|> > In my opinion the default should ensure portability and that
|> > extra work by the application engineer should be required to
|> > utilize implementation-specific features.
|> 
|> If I wanted a compliance tester, I would have downloaded one from
|> The Open Group. They have one on their web site.

non sequitor.   Individuals who are developing applications
should always be aware of the areas of their application 
which may have portability concerns, even if the developer
doesn't believe that the application will ever run on another
platform, _never_ is a long, long, long time.

|> 
|> I don't want a compliance tester.

And I guess you aren't charged with developing portable
applications either.  

scott lurndal
Silicon Graphics, Inc.		(I speak for myself)
-
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