Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 9 Oct 1999 19:47:34 +0400 (MSD) | Subject | RE: [linux-usb] Re: USB device allocation |
| |
In <Pine.GSO.4.10.9910090850100.14891-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:
AV> On Sat, 9 Oct 1999, Sergey Kubushin wrote:
>> The devfs quasifiles _ARE_ renamable:
AV> Learn to read. And look through the patch, damnit. ->i_op->rename is NULL. AV> <quote> AV> +static struct inode_operations devfs_iops = AV> +{ AV> + default_file_ops: &devfs_fops, AV> + lookup: devfs_lookup, AV> + link: devfs_link, AV> + unlink: devfs_unlink, AV> + symlink: devfs_symlink, AV> + mkdir: devfs_mkdir, AV> + rmdir: devfs_rmdir, AV> + mknod: devfs_mknod, AV> + readlink: devfs_readlink, AV> + follow_link: devfs_follow_link, AV> +}; AV> </quote>
AV> Oh, and man strace, please.
:-))
>> The "good ol' way" is good only till it doesn't stop the progress. It was >> very good to have a live horse as an engine for a cab, but once upon a time >> a man called Henry Ford did start to manufacture a new cabs called Ford T and >> the live horse had became obsolete...
AV> You are missing the career of politician...
AV> ObLiveHorses: this one is _long_ dead. What about dropping all political AV> drivel to hell where it belongs and moving the _technical_, _kernel-related_ AV> part of the thread to fsdevel?
Just since it does not belond to fsdevel. devfs is more then filesystem...
And IMNSHO it's main problem with it. It's few things in one patch. I see at least two: 1) name-based (not major/minor based) way of registering devices 2) way to expose such name-based devices in filesystem under /dev (or /devices, or /dev) May be it should be splitted even more. Most peoples object against devfs per se but NOT against more advanced scheme of device registering (quite a few devfs antagonists like idea of central depositary where all drivers in kernel are registered and you can see full list via some interface). On other hand most fluidal and unstable part of devfs patch is exactly handling of such tree and not devfs per se. It's possible to make different way to expose such information (for example "old style" /dev plus devd to make it dynamic) and compare them. Even if such information will be only available to special "device installation" program without any dynamic /dev it'll be usefull thing. THEN devfs will become MUCH less fluidal patch and deiscussion will really belond only to fsdevel...
AV> Sigh... What a pity that there is no NoCeM analogs for MUAs...
- 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/
| |