Re: Reflection and /proc

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

In article <7benjr$9sudr@fido.engr.sgi.com>, Albert D. Cahalan <acahalan@cs.uml.edu> wrote :
|> Charles Cazabon writes:
|> > Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
|> 
|> >> Wrong. We have hit the mainstream; we can set the standards.
|> >> Everybody is following the Linux API now. (UnixWare, BSD...)

Actually, they are following the linux "ABI", and only for the parts
that are standardized.   They still maintain and enhance the native
ABI and API - they simply are allowing for additional application capture by
allowing some subset of the Linux applications to execute as well.

Note that they won't allow linux applications that, for example, use
/dev/kmem or the extremely non-standard linux version of 
/proc to execute correctly.

|> > 
|> > 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
tried to get us (xopen) to adopt the sparse malloc() implementation
as standard - however it was considered onerous for portable
applications to have to deal with SIGSEGV instead of a 
NULL return from malloc when memory was tight and non-determinism
was considered bad]

|> 
|> > Breaking convention needlessly is just as bad as the Microsoft
|> > "embrace and extend" philosophy.
|> 
|> We already break convention in many _bad_ ways. We might as well
|> break it in good ways too. Nobody wants BlandOS.

Boloney.  Fix the bad areas.  Don't add more.  Nobody really cares
about the OS (with the exception of a vocal minority, most people
don't care about the _OS_, they care about the applications that
they run).

|> 
|> We've already done "embrace and extend" on the editor concept.
|> Just look at what emacs does. The compiler has extra stuff too.

No one who writes portable software uses the non-standard extra
stuff that gcc and g++ provide.   Linux itself can get away with 
using it as it doesn't need to be compiled by any other compiler
(athough it would be beneficial if it could - gcc doesn't necessarily
compare well to commercial compilers [non-microsoft, that is]).


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

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

|> 
|> 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. Standard
explicitly doesn't specify the return value of fputs because the two 
unix universes handled it differently. 

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.

|> 
|> 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.   All the configurable
values for the sem, shm and msg subsystems should be exported
via the 'sysconf()' API, while no standard exists for this, it
would be a viable extension.

the key and seq members of the ipc_stat structure are private to
the implementation and may not be used by portable applications.
(see XPG4/XPG4.2/XPG5 <sys/ipc.h> entry); in fact several implementations
of sysv ipc do not utilize the seq member at all.

|> 
|> signal() behavior is now incompatible with both libc 5 and UNIX(TM).
|> It follows the non-standard BSD behavior now, gratuitously breaking
|> old software in hard-to-detect ways. 

I'll agree with you here, signal() should behave as spec'd by POSIX 
and adopted by the Open Group.

Modern portable applications should use sigaction() and avoid the
problem entirely.


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

Both POSIX and the Open Group have a very clear idea of how to 
compile portable applications without namespace pollution.  
(-D_POSIX_C_SOURCE=2 for posix, and -D_XOPEN_SOURCE (which is required
to implicitly define -D_POSIX_SOURCE -D_POSIX_C_SOURCE) for X/Open
extensions to the POSIX requirements.

Most implementations provide the rich native API as the default
API and require the application writer to specify that a restricted
compilation environment is required. 

However, it is the implementation's choice which namespace to 
provide as the default 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.

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