Subject: Re: 32 bit dev_t, Revision 2
To: Paul A Vixie <paul@vix.com>
From: Darren Reed <darrenr@cyber.com.au>
List: tech-kern
Date: 01/12/1998 13:13:40
In some mail I received from Paul A Vixie, sie wrote
[...]
> back on topic, can someone 'splain to me why device special files are still
> inside a UFS/FFS container with special "MAKEDEV" scripts?  if we can do
> /proc it seems to me that /dev can be a special file system whose entries
> are _made_ at successful probe time, using monotonically increasing dev_t's
> with an opaque internal structure?  ted says this has been done in some
> form.  if we're going to pull dev_t through a knothole backward and touch
> the kernel in 125 places to do it, why not do the Right Thing and just stop
> trying to figure out whether 12/20 is a good split or whether MI and MD need
> different ranges and whether one or two tables are the right approach.  we
> KNOW this isn't the right approach, why are we taking it anyway?

My perceived problem with this is how do you maintain knowledge of what the
major/minor, owner and permissions are of those device nodes across a
reboot ?

I don't expect a driver to set those itself.

Otherwise, I agree that this is the right thing to do, although there still
needs to be a split for major/minor bits, the size isn't as critical for
major numbers (but should not be less than 8 bits).

Darren