True. Please everyone: let's keep this civil.
> Indeed, I haven't made any arguments because it's clear the devfs folks
> are fanatical about the subject. My plan was to actually implement a
> better alternative, not just argue about it. The only reason why I
> broke my silence was to point out that not all of the "Linux Kernel
> Gods" (not my terminology) thought devfs was the greatest thing since
> sliced bread, as one person on the mailing list had incorrectly claimed.
I hope you don't feel I'm a fanatic. Yes, I strongly believe in the
correctness of the idea. And I've not yet heard of practical solutions
to all of the problems devfs fixes.
> My best guess is that devfs is more like GGI in terms some folks who
> think its great and some folks who think it's kinda ugly. Obviously
> it's different folks, and different objectives; suffice it to say that
> not every one agrees.
Unfortunately the people who disagree haven't:
- explained *why* devfs is ugly and yet the existing scheme isn't
ugly. Yes, I think the existing scheme is ugly. What makes *you*
right and me wrong on this issue?
- given practical solutions to all the problems devfs fixes.
> Well, put simply, (1) it's trying to solve a problem in the kernel for
> which parts can just as easily be solved in user-space; it puts too much
> policy and naming issues in the kernel. (2) The hacks that you need so
> that you can save the user/group ownership and permissions are too ugly
> to contemplate. (3) Device inodes really do need major and minor device
> numbers; programs do look at them, and POSIX guarantees that they exist.
1) devfs doesn't have to be mounted onto /dev if you don't like. The
essential thing is that devfs provides a unique, logical
namespace. You can always mount devfs elsewhere and make symlinks
to it if you don't like the names
2) which hacks are these? You mean using tar to save and restore the
permissions? Would you prefer a C programme (something I'm
contemplating doing)
3) devfs keeps the device numbers. It just doesn't *require* a driver
to choose one, allowing for automagic generation of unique device
numbers. I don't plan on breaking POSIX. It just breaks the kernel
dependency on device numers, providing a faster, simpler path from
userspace to the driver.
> The one problem which devfs is trying to solve which I think is valid is
> the question of device partitions, particularly with SCSI.
What about the problem of when we move to 16 bit majors and the major
table is dropped and we go to searching a list when we open a device
node? How do you suggest we solve that?
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html