Subject: Re: 32 bit dev_t, Revision 2
To: Paul A Vixie <email@example.com>
From: Darren Reed <firstname.lastname@example.org>
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
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).