Re: extended partitions

Glenn Moloney (glenn@physics.unimelb.EDU.AU)
Wed, 18 Oct 1995 01:29:03 +1000

Hi all,

> From: Jim Nance <>
> > If the names in /dev are generated directly by the kernel, like /proc
> > is, this problem disappears.
> 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. Registering major numbers can be problematic, and I
was thinking of the driver automatically trying other major numbers,
if it could not register at the requested major number. The entries in
/proc/somewhere would automatically have the correct major/minor
numbers for the installed driver.

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

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. With the suggested scheme, the
major/minor numbers and default permission bits are controlled by the
kernel and device drivers, but customisation is possible with an
external program for permission bits and symlinks (device name
aliasing). There is no need to keep the kernel and device drivers
coordinated with an external program (MAKEDEV) to manage major/minor
numbers and permissions.

> From: Bob Lanning <>
> > 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.

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


  Glenn Moloney
  School of Physics,			Phone: +61 3 9344 5081
  University of Melbourne,		Fax:   +61 3 9347 4783
  Parkville, Australia 3052.