On Mon, 22 May 2000 jmcmullan@linuxcare.com wrote:
>
> From: jmcmullan@linuxcare.com
> Date: 22 May 2000 07:41:09 +0200
> Subject: Re: devfs - the missing link
>
> James <james@amethyst.nurealm.net> wrote:
> > I read through Neil Brown's reflections on the devfs, picked up by the Linux
> > Weekly News. I have some thoughts to share, somewhat naive, as I haven't
> > been following the devfs debate very closely.
> >
> > [Really-big-snip-of-stuff-that-should-go-into-a-whitepaper-or-something]
>
> <RANT TIME="latenight" MODE="ramble">
>
> James brings up a lot of interesting observations, all of which seem
> to clustered around a few main points:
>
> *) UNIX traditions: Why do we keep hanging on?
Because it was a model that worked and worked well, and there is
a large applications base dependent upon this model, and a large user base
dependent upon this applications base.
> The UNIX device major/minor system has been around since the
> early 80s, if not earlier. The major/minor system was originally
> designed to function in exactly the way James envisions:
> class::instance of class. The major number was the device driver
> identifier, and the minor number was the particular hardware instance.
>
> This system was designed for, and worked well on, minicomputers
> and mainframes with a) limited device types b) few instances per
> type and c) limited, and propriteary, future devices. However, the
> PC class of system fails all three of the original design constraints.
> I find it amazing that the major/minor system has lasted this long.
One of the major reasons I was attracted to Linux was the hardware
platform independence. I can run it on a PC, and I can run it on Sparc, and I
can run it on MIPS, and....
I really really dislike the push to make it a "PC Only" OS again. If you
really want this, go back to .98 which I believe was pretty much limited to 386
boxes.
This device tree model that some other modern Unix's have adopted really
sucks eggs, it makes it a bitch to find something when something breaks and
provides an unnecessary additional level of abstraction. If, searching a large
directory is so ineffecient, then the source of that ineffeciency should be
fixed.
And here I have major qualms with the direction Linux is taking in
general, way too much emphasis on the latest whiz-bang features and
capabilities, and almost zero on basic code correctness. Really fundamental
things like memory management don't work right. Race conditions, spin_lock
deadlock problems abound.
When changes are made for the hell of it and no real functional reason,
it just adds more opportunities for bugs to creep in and breaks existing
applications.
For example, here I have a mixed environment of SunOS and Linux boxes, and
the Linux boxes are on different platforms. When 2.2.x came out, changes to
the /proc structure broke rpc.rstatd, so perfmon no longer functioned. I found
versions of rpc.rstatd that were crudely hacked for 2.2.x but none of them
worked right on multi-CPU platforms. I finally crudely hacked one to work
myself. Even then I have to tweak it when I compile on platforms with
different version of the libs and the include files because of changes to what
is defined in the include files on every version of Linux that is kicked out.
Someone somewhere thought it would be a good idea to include seperate
information on each CPU, each disk, and add extra fields to the existing /proc
structure, and I'll grant you the additional capability is good. But no
thought was given to backwards capability and it broke existing applications.
To use a physical analogy; One should fix the foundation before adding
more floors onto the building. When one adds on to an occupying building, one
has to give some consideration to the needs of existing tenants. Fancy trim
around the windows doesn't count for much when you're freezing your ass off
because there is a 20 foot gaping hole in the wall. Fix the hole first then
add the fancy trim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:22 EST