Re: Reflection and /proc

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

In article <7bq1i4$ast7g@fido.engr.sgi.com>, you write:
|> Scott Lurndal writes:
|> > In article <7bif65$acft3@fido.engr.sgi.com>, you write:
|> >> 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
|> >
|> > Hmm..  Aren't we discussing Linux on intel ia32 here?
|> 
|> Yes, along with Alpha, PowerPC, MIPS, SPARC...
|> 
|> We might let lseek() be limited on 32-bit hardware, but the other
|> two are still important. I think FreeBSD made lseek() work right
|> on 32-bit hardware.
|> 
|> I just checked their web site. FreeBSD only supports lseek().
|> Since I know FreeBSD supports huge files and there is no mention of
|> a size-related error, it seems to me that they have a 64-bit lseek().

As may be.  As it happens, I originally championed a scheme
to utilize the existing interfaces (open, lseek, read, write, stat), 
etc. with 64-bit off_t and size_t fields where appropriate during
the LFS meetings a few years ago.   It was easy for me to champion
such a proposal because my employer, whom I was representing, 
currently had no customers yet for a new Unix-based system.   This 
allowed us great leeway in designing the API as we didn't have
any existing customer base to worry about.    Fortunately, the
rest of the vendors on the LFS committee did, and I was quickly
convinced that the available solutions (parallel /usr/include, 
/usr/lib, e.g.) were quirky and untenable.   Ultimately, after
a couple years of discussions and meetings, we settled on what
you see today (I originally wanted to do something very similar
to the EFT (expanded fundamental types) program which was part of
the SVR4.0 base delivery which changed various fundamental types
like the size of pid_t, uid_t, gid_t (16 to 32 bits), et. al.
(which led to the creation of such system calls as xstat() and
xmknod() on svr4 systems).   The problem was that not all systems
were based on SVR4, so many didn't have the infrastructure 
in place to allow graceful migration to larger off_t (and even
SVR4 was missing some things).

|> 
|> This makes sense; why should we change everything to lseek64()?
|> It is better to fix lseek(). Of course, Linux should still support
|> both lseek64() and llseek() for compatibility.

Fixing lseek() is much easier to say, than to do, I'm afraid and
will probably never be done for ia32.   ia64 will be the next 
opportunity to change.

|> 
|> >>> 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.
|> >
|> > Have you ever worked for a kernel vendor?  I've done kernels on
|> > everything from mainframes through MPP boxes and without exception
|> > every feature that has been put into those operating systems
|> > has gone through a rigorous design process (not all vendors
|> > do this, but the older, established ones do);  I've got the scars
|> > from the design reviews to prove it :-)
|> 
|> If you try to shoot down a feature that is supported by someone with
|> political power, you will hurt your career. (you've "got the scars")
|> Most people don't want to make enemies.

Now you are drawing unwarranted conclusions.   First of all, you are
ascribing too much to politics.   Certainly no matter how vociferously
that I have opposed (or championed) a particular feature, it has
never hurt my career; on the contrary, it has helped.  

Design reviews are based around honesty, sometimes brutal honesty.  Without,
the design review is useless.   Thus, periodically, there are acrimoneous
debates as various engineers discuss architectural and implementation
issues.   All good, by the way, even if they don't necessarily seem so
at the time.  If you've made it to the detailed (or even conceptual)
phase of the design process, it is past the point where the project
will be "shot down" as you put it, the work at that point is to come
up with the best design possible that satisfies _all_ constraints.

|> 
|> >>> 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)
|> >
|> > I see we have a basic difference in philosphy, here.
|> 
|> Yes, but not a huge one. I do not suggest ignoring standards as a way
|> to force people to write Linux-specific code. That would be evil.
|> I don't even suggest creating duplicate functions to cause trouble.
|> 
|> I only suggest:
|> 
|> 1. support foreign extensions (stuff from AIX, Solaris, Irix...)
|> 2. support old Linux features
|> 3. feel free to create useful features

And I suggest that you do this in moderation, extreme moderation. 
Bloat sucks, believe me.

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