No. Used symlinks, which, with devfsd, BTW, are persistent.
>There is an even thinner layer that does that, called mknod(8)+chmod(1)...
Jeezo cheeso, buddy, are you ignoring the major/minor limitation thing here,
or what???
>> use of a limited dev_t through dynamic allocation. Increasing dev_t size
is
>> still not going to make hot-plug things like USB clean.
>Neither is any "dynamic" name assignment, where names are compiled into the
>kernel (see above). As none of the alternatives (devfs and increased dev_t)
>really solves this problem, which clearly is the central point of the
>exercise anyway, we have to look for something else.
You've lost me.
>It is a complex mechanism to buy exactly what we had before. Violates KISS.
What you had before was limited, and not sustainable.
>This has security implications... if I can somehow mount devfs with _my_
>machinery to handle permissions (needed for "random user plugs in USB
>floppy", perhaps), the system is screwed. Again, goes against KISS.
You can chmod/chown/ln in the devfs, and it's persistent.
>Not proven, AFAIKS.
Then you are ignoring the arguments for it.
>What is needed is a way to address _data_, not _devices_. A user cares
>about the document she is writing, not about "USB SCSI controller 2, device
>14, partition 6, inode 417". The Unix way of handling files solves this for
>_fixed_ devices. For _removable_ devices (or media), I know of no real
>solution. Throw in the possibility of getting at data over FTP, HTTP, NFS,
>and whatnot (ultimate removability ;-).
Now you've abstracted everything to a way beyond level. You want your OS to
use URLs??? Why don't you KISS yourself! I mean, you just blasted devfs for
being too complex!!! Have you EVER used it? Did you even read the FAQ?
-Shawn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/