mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: mpm@selenic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Future devfs plans (sorry for previous incomplete message)
Date: Tue, 27 Jul 2004 21:16:02 -0700	[thread overview]
Message-ID: <200407280416.i6S4G1P04614@freya.yggdrasil.com> (raw)

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

             reply	other threads:[~2004-07-27 13:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28  4:16 Adam J. Richter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-07-26 17:37 Adam J. Richter
2004-07-26  3:34 ` Tim Connors
2004-07-26  6:24 ` Trent Lloyd
2004-07-26  6:32   ` Norberto Bensa
2004-07-26  7:11     ` Alexander E. Patrakov
2004-07-26  9:09   ` Måns Rullgård
2004-07-28  0:12     ` Trent Lloyd
2004-07-28  1:43       ` Måns Rullgård
2004-07-26  9:38 ` Ville Herva
2004-07-27  1:03 ` Matt Mackall
2004-07-28  3:16   ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200407280416.i6S4G1P04614@freya.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®