Re: Future devfs plans (sorry for previous incomplete message)

[Adam J. Richter]

Matt Mackall wrote:
>On Mon, Jul 26, 2004 at 10:37:41AM -0700, Adam J. Richter wrote:
>>       devfs allows for creation of devices when user level programs
>> need them rather than based on "hot plug" or modprobe-related events,
>> neither of which do not exist for many devices and do not necessarily
>> indicate need for the driver.
>
>One wonders if autofs can be made to do the same.

	Although I never experimentally confirmed it, from reading
the autofs and autofs4 sources, it appears that neither of them
provide a mknod operation.  They both use simple_inode_operations,
which has a NULL mknod, which will cause vfs_mknod to return -EPERM.
I believe autofs and autofs4 only allow creation of directories
and symlinks.

	Also, as I mentioned previously, trapping
inode_operations.lookup() can deadlock driver initialization
if it is doing mknod's that would also trigger that lookup
trap.  The VFS interface to lookup() could be changed slightly
via an extra parameter or an extra field in dentry or nameidata
to allow the lookup() trap to skip mknod and mkdir attempts,
but it might require some 1 line changes in a 50 file systems,
and I think doing it as an extension to dnotify might have
other minor benefits, such as demand loading appropriate modules
when files like /proc/apm or /proc/microcode are opened.  However, I
think it's a very close call whether to do the lookup trapping as a
file system modification or a VFS/dnotify modification.

                    __     ______________ 
Adam J. Richter        \ /
adam@xxxxxxxxxxxxx      | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/