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/