Re: Migrating to larger numbers

David Weinehall (tao@acc.umu.se)
Tue, 8 Jun 1999 14:05:41 +0200 (MET DST)


On Mon, 7 Jun 1999, H. Peter Anvin wrote:

> Richard Gooch wrote:
> > >
> > > devfs is based on a completely bogus idea: that a device driver is a
> > > kernel thing. *THIS* is the supreme fallacy, and a major pitfall for
> > > Linux today. devfs in fact helps perpetualize this problem, in large
> > > part by moving policy into the kernel that has no business being there.
> > > It's the DOS way of fixing things -- quick, dirty, and extremely
> > > short-sighted.
> >
> > Oh, come on! Of course a device driver belongs in the kernel. We're
> > not a microkernel, you know.
>
> You have the completely wrong idea what a device driver is! XF86_SVGA
> is a device driver! gpm is a device driver (mouse driver.)
> magicfilter/ghostscript is a device driver (printer driver.) Neither
> belong in the kernel.

Classifying this way, you could actually say that every binary is a device
of one way or another... Pine is a network-driver of sorts, vim is a
driver for changing information on disks, etc.

> Things belong in the kernel if they *have* to be there. Not otherwise.
> This implies the need for a coherent, *USER SPACE*, setup for managing
> devices. Bootup devices are somewhat a special case, of course, but
> that doesn't change the fundamentals.
>
> > Anyway, you talk about this major pitfall which is a problem. *What*
> > is this "problem"?
>
> The whole design philosophy behind this. "Throw all the crap in the
> kernel, it's the easy solution."

Excuse me, but exactly what makes Unix device#'s any better here? I can't
see any way they simplify for userspace Device-drivers.

/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

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