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

From: Adam J. Richter (adam_at_yggdrasil.com)
Date: 07/28/04

  • Next message: Ed Sweetman: "Re: OOM-killer going crazy."
    Date:	Tue, 27 Jul 2004 21:16:02 -0700
    To: mpm@selenic.com
    
    

    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@yggdrasil.com | 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Ed Sweetman: "Re: OOM-killer going crazy."

    Relevant Pages

    • [PATCH 0/5] [RFC] New path lookup function (V3)
      ... Currently, such file systems use ... not passing a lookup intent, for example, can trigger BUG_ON's ... The second patch changes sunrpc to use vfs_path_lookup. ... kernel doc comment for vfs_path_lookup (hch) ...
      (Linux-Kernel)
    • [PATCH 0/4] [RFC] New path lookup function
      ... Currently, such file systems use ... intent along; not passing a lookup intent, for example, can trigger BUG_ON's ... The third patch changes nfsctl.c to use path_component_lookup. ...
      (Linux-Kernel)
    • Re[3]: vn_fullpath() again
      ... > How do you feel about small incremental improvements to name lookup? ... This would be implemented by file systems like ... procfs and devfs to handle cases where the name cache wasn't used. ... >> fundamentally second class systems in the file system and VFS design. ...
      (freebsd-hackers)
    • [PATCH 0/1] [RFC] New mode for path_lookup (V1)
      ... Stackable file systems frequently need to lookup paths or path components ... starting from an arbitrary point in the namespace (identified by a dentry ... frowned upon as it does not pass the lookup intent along; ...
      (Linux-Kernel)
    • Re: Database terminology
      ... word "lookup" has such a negative connotation for me... ... "and thou shalt abhor the use of "Lookup Fields" which art the creation ... of the Evil One." ...
      (microsoft.public.access.tablesdbdesign)