Messages in this thread | | | From | Shawn Leas <> | Subject | RE: devfs again, (was RE: USB device allocation) | Date | Wed, 6 Oct 1999 14:32:57 -0500 |
| |
>Names _are_ policy. So now I have to hack the kernel to rename the mouse?
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/
| |