Re: Reflection and /proc

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

Scott Lurndal writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>> Scott Lurndal writes:

Please stop the incompatible quoting style. Non-standard enhancements
are fine, but you need to get the standards right too.

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

Nobody proposed doing that, although glibc already does do it.

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

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

> This is just as bad as microsoft locking applications into NT.

...and Apple and Sun and SGI (yes, you!) and...

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

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

The code was already excessively portable, using a configure script
to choose one of lseek, llseek, lseek64, and assembly code. This script
broke when the glibc people removed the prototype but kept the code.
(the compiler does not pass 64-bit values correctly without a prototype)

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

Backwards compatability is highly regarded by key kernel developers.
The library developers don't care. Loss of backwards compatability
hurts very much. Linux 2.0 kept a bug rather than break Real Audio.
Linux supports a large collection of obsolete system calls.

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

Your point? They still support llseek, as we ought to do.

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

> Now, all commercial unices have proprietary extensions

Linux should not be any different.

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

So why do you insist that extensions be killed?

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

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

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

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

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

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

If that is so (though I don't agree), then individuals who are
developing applications should always use a compliance tester.
Feel free to do so if you prefer.

The default should include all features that don't conflict.
When features conflict, choose the SysV version.

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