> If the names in /dev are generated directly by the kernel, like /proc
> is, this problem disapears.
Great Idea. Exactly that way it is done in DataGeneral's DG/UX and I like it.
One could decide if a device is built into the kernel by simply looking in
/dev.
Bye, Jojo
------------ ORIGINAL ATTACHMENT --------
SENT 10-07-95 FROM SMTPGATE (dholland@hcs.harvard.edu)
> > > [...] 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