Re: extended partitions

David Holland (dholland@hcs.harvard.edu)
Sat, 7 Oct 1995 12:43:52 -0400 (EDT)

> > > [...] following that argument leads to the conclusion that we don't
> > > need /dev at all -- just build those names into the kernel and be
> > > done with it.)
> >
> > We don't, and we should, respectively.
>
> that would REALLY limit the ease of user level access. i.e.
> most shell scripting languages can access the devices as simple files
> currently. to be able to access these devices as kernel calls
> exclusively, would mean having to retro-fit the kernel access hooks for
> any program that wants access.

Pardon me, but what the *hell* are you talking about?
Not what I am, obviously.

/dev exists to support a mapping between device names (eg, hda1) and
major/minor number pairs (eg, (3,1).)

This mapping is maintained by MAKEDEV. Sort of. It's very easy for
MAKEDEV to be wrong or just out of date. It's also very easy to have
additional bogus devices lying around. The last Slackware I saw (which
is not the most recent) had a few dozen bogus entries in /dev that
didn't point to *any* device at all. What happens if you make an entry
called "null" in /dev that's (3,1) instead of (1,3)? Anything
accessing "/dev/null" actually trashes the first partition of the
first IDE disk. This is not a good situation.

If the names in /dev are generated directly by the kernel, like /proc
is, this problem disappears. 

-- 
   - David A. Holland             | Average number of times an American 
     dholland@hcs.harvard.edu     | opens the refrigerator each day: 22