Re: extended partitions

Zygo Blaxell (zblaxell@calum.csclub.uwaterloo.ca)
Wed, 18 Oct 1995 13:16:44 -0400 (EDT)


Quoted from Glenn Moloney:
> > From: Jim Nance <jlnance@isscad.com>
> > The existance of /dev as a real, rather than a virtual file system allows
> > device permissions to be set, and remain set across reboots. I must admit
> > that I think the idea of a virtual /dev does have an attractive eligance,
> > however, I have never seen any proposal which would fix the device
> > permission problem.
>
> Well, I've been thinking about the usefulness of having a device
> driver I wrote (am writing) create device entries in
> /proc/somewhere. [ ... ]
>
> The permission bits could be set when the driver module is loaded, or
> on the kernel command line. Also, the /proc filesystem could be
> extended to allow setting permission bits, and customisation of
> permission bits could be performed by a start-up file
> (/etc/rc.d/rc.devices).
>
> I realise this may seem complicated to all of us familiar with /dev,
> however, I believe it is simpler than the current combination of
> MAKEDEV and the kernel device drivers.

One of the important things about MAKEDEV and the kernel device
drivers is that the overhead of storing the device names, permissions,
directory structure, symlinks, etc. is stored on your hard drive (at
$0.25/meg) instead of in RAM (at $45.00/meg). Granted, when you open a
device it's in RAM as well, but at least it's _not_ in RAM when it's
_not_ open.

> [...] There is no need to keep the kernel and device drivers
> coordinated with an external program (MAKEDEV) to manage major/minor
> numbers and permissions.

One solution is to create an rc.dev file that runs MAKEDEV at boot time.
For standardization purposes, it should be a part of the kernel sources or
distributed through the current kernel distribution channels (Hi, Linus!).
Ditto, IMHO, for everything else that only configures Linux-specific
things, like setserial, tunelp, ifconfig/route/netstat, kbd (which is
already distributed this way), hdparm, setfdprm, fdformat, cdtester
(buried in drivers/block), and other fun tools that keep getting out
of date. This way, everybody gets one standard up-to-date MAKEDEV every
4.3 days or so (depending on how fast Linus is that week ;-).

I used to hate this idea, until I got so fed up with insane values for
PTY/TTY ownership/permissions that I put explicit chown/chmod into my
rc scripts.

Therefore, I propose: register the minimal set of devices and give them
constant major numbers. So /dev/tty*, hd*, sd*, xd*, fd* and /dev/zero
are constant, because you have to be able to boot from them, or open
them before you get to run MAKEDEV.

Everything else gets allocated dynamically and the results of that
allocation accessible through /proc. Maybe have register_{chr,blk}dev
print out these allocations on the console, so that people know what's
going on. MAKEDEV is run before filesystems are mounted. It removes
old /dev entries and creates new ones using the hints from /proc.

One thing I'd _love_ to see is /dev/sdh0c0t0l0p1 instead of /dev/sda1
(where sdh0c0t0l0p1 = scsi disk hostadaptor 0 channel 0 target 0 lun 0
partition 1). I hate the fact that if a drive doesn't start one
morning, your system proceeds to hose itself by swapping on the next
disk in the chain, or dies horribly because the news spool is mounted
where /usr should be. This way the mounts fail, which is much better
than the wrong mounts succeeding.

> > From: Bob Lanning <lanning@tidbit.fhda.edu>
> > > If the names in /dev are generated directly by the kernel, like /proc
> > > is, this problem disappears.
> >
> > And what about links like /dev/cdrom, /dev/modem, and /dev/mouse?
>
> The /proc filesystem could be extended to support symlinks, and
> preserved across reboots with the above mentioned config file.

For those who are considering kernel solutions, bear in mind that I
won't run a /dev that doesn't support multiple mount points, no implicit
insertion of entries, and permanent explicit removal of entries.

We have a secure Linux box upstairs that puts every user into their
very own private chroot environment, complete with its own private /dev
entries. /dev/fd0 had better _not_ appear automatically when
you insert a floppy/insmod the floppy driver, or other "cute" things
like that. That would be a really Bad Thing.

> The BIG problem I see with the above is that it is non-standard
> (whatever "standard" is).

If you've seen a standard anywhere, I'd like you to convince all of the
vendors I've had to use to follow it. ;-)

However, there is clearly a precedent for /dev, and on some systems
(notably the closer to 'original' Unix you get, the closer to this ideal
you get), everything, including network drivers, has to go through
something in /dev. This is (was) a good thing, because then Unix
filesystem permission structure applies uniformly to everything a
process can get access to in Unix.

Nowadays that's less true. You don't need to access any files at all to
create and use Internet sockets, or even to configure them now.
/proc/[a-z]* will happily tell you things about system configuration.
Memory isn't allocated through the filesystem, and never was.

Personally, I'd prefer to move things from /proc to /dev. It would
allow us to un-setuid things like pppd (which could be setgid instead).