>  > 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?
> 
> Um.. probably because:
> 
> 	(1) There are several problems with a "devfs" approach, including
> 	    non-persistence of chmod's and symlinks.
> 
> 	(2) There are some programs out there that like to compare dev_t's
> 	    to see if e.g. file foo is on the same file system as file bar.

 (3) AFAIK, dev_t's of block devices with NFS exported filesystems
     must be persistent across reboots and reconfigurations
     (this can be avoided with translation tables in server code
      filled by /etc/rc from database file but that's really ugly IMHO).

I would like devfs as optional filesystem, that anybody who knows what he is
doing could use as target of custom symlinks created in normal /dev.

Compatility & prior art:
Solaris looks like this if you delete /etc/rcS.d/S60devlinks :-)


-- 
Zdenek Salvet                                              salvet@ics.muni.cz 
----------------------------------------------------------------------------
           If God had meant for us to be in the Army,
         we would have been born with green, baggy skin.