lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [linux-usb] Re: USB device allocation
    In <199910092346.TAA17860@tsx-prime.MIT.EDU> Theodore Y. Ts'o (tytso@mit.edu) wrote:
    TT> Date: Sat, 9 Oct 1999 17:33:56 +0100
    TT> From: Kernel Stuffs <kernel@gladden-fields.demon.co.uk>

    TT> On Sun, Oct 10, 1999 at 12:30:06AM +1000, Nathan Hand wrote:
    >> Devfs as a filesystem doesn't do enough. You still need a user space
    >> daemon to do more complex things. For example, plugging in a hotswap
    >> isdn card shouldn't just create /dev/ppp, it should also fire up the
    >> ifconfig and pppd processes. There are other (better) examples.
    >>
    >> And once you admit you need a user space daemon, then you can accept
    >> that you don't *need* devfs as a filesystem. You can achieve most of
    >> devfs's functionality using a user space daemon. I particularly like
    >> your idea of select/poll on /proc/devices.

    TT> Sounds like the desrcription of what kerneld was supposed to give
    TT> the kernel that I read a couple of years back when I first started
    TT> with linux. This whole argument just seems to go round in a circle
    TT> over and over again.

    TT> No, there's a big difference. The problem with kerneld is that the
    TT> kernel had to wait for the user-space daemon to respond before it could
    TT> complete some action, such as opening a device, reference some new
    TT> network protocol family, touch the PPP or SLIP driver, etc.

    1. And now kernel should wait for modprobe to respond :-) modprobe is not in
    kernel anyway (and does not belond there IMO).
    2. How about accessing of /dev/printer/0 when printed module is NOT in memory
    and so /dev/printer/0 is NOT there ?

    TT> This turns out to be a bad idea, or at least very hard to get right,
    TT> since you have to handle the cases where kerneld is swapped out, or can't
    TT> respond in time, etc. Blocking a kernel-space execution path while you
    TT> wait for a user-space process to respond is an invitation to deadlock.

    But I can not see how kmod changed it: you still should wait for vfat.o to
    be loaded by modprobe before mount() can be completed...

    TT> The difference here is that what we're providing is a unified scheme by
    TT> which the kernel *notifies* a user-space process that some new device
    TT> has appeared on the scene. It's a one-way communication, with no requirement
    TT> that kernel code wait for the user-space process to do whatever it needs to
    TT> do.

    When someone tries to access device for which module is not loaded kernel code
    SHOULD wait for the user-space process to answer "which module should be loaded
    for this device to appear in /dev". No, it's two-way process :-(

    TT> The user-space daemon can ignore the event; it
    TT> can create a node in /dev; it can initiate a GUI dialog box asking the
    TT> user what how some new device should be configured; it can play "God
    TT> Save the Queen" in three-part harmony using the multimedia speakers.
    TT> It's completely up to user-space daemon, so it's therefore much more
    TT> flexible than a kernel-only devfs scheme.

    Unfortunatelly it's not so: you CAN do thing with user-space daemon not even
    imaginable with kernel-only devfs but you also CAN NOT do some things already
    done in Richard's devfs.

    TT> From: Khimenko Victor <khim@sch57.msk.ru>
    TT> Date: Sat, 9 Oct 1999

    TT> Great. Such problems should be and can be fixed before devfs will be
    TT> accepted (in 2.5.x -- it's to late for 2.3.x) even if they are not
    TT> trivial. But looks like you are the only one who cares about
    TT> technical problems with devfs and not political ones :-/ All other
    TT> folks (including Theodore Y. Ts'o and H. Peter Anvin) object against
    TT> devfs IDEA, not against IMPLEMENTATION.

    TT> I'm all in favor of the IDEA of a dynamic /dev directory. What I'm
    TT> against is the IMPLEMENTATION that is devfs.

    IDEA behind of devfs is NOT IDEA of a dynamic /dev directory. It's idea that
    /dev should be what name implies: direct link to device drivers. That is
    without any indirect major/minor numbers and such.

    TT> You are right where you say that part of the problem with devfs is that
    TT> there's a huge pile of different changes all lumped into one patch. In
    TT> no particular order, there is:

    TT> * A standard interface which is used by devices to register the
    TT> existence of new device nodes
    TT> * A way of maintaining this information in a tree-like structure
    TT> * Patches to change over from a (major, minor) device number
    TT> scheme to a name-based scheme.
    TT> * A /proc-like filesystem

    TT> Because there are so many things intertwined into one patch, it makes it
    TT> difficult to talk about it and reason about it, even for advocates of
    TT> devfs. The folks who claim that "you don't have to use devfs"
    TT> conveniently forget about the ultimate goal of Richard Gooch's to get
    TT> rid of major and minor device numbers. And, the folks who argue that
    TT> the patch is good because it nukes major and minor devices are
    TT> contradicting those who say "you don't have to use devfs". When you add
    TT> to this Alex Viro's observation that you can't mount devfs in more than
    TT> one place, the fact that you need selected devices in places other than
    TT> /dev (in ~ftp/dev to anonymous FTP work, for example) shows us that the
    TT> patch simply isn't ready for prime-time, and so because it's one whole
    TT> gigantic lump, the whole patch gets rejected.

    TT> A patch which only did the first, and maintained the information in a
    TT> flat linked list (the tree structure is as part of the name is a policy
    TT> that doesn't belong in the kernel; let the user-space daemon or the
    TT> separate devfs module take care of that) would likely have a much better
    TT> chance of being accepted.

    Hmm. What'll be registered in such a list ? IMO some "default" name of device
    SHOULD be supplied by device driver. So when you got driver for brand new
    device for which there are no information in userspace daemon such device
    still can be used somehow (even if name for such device will be ugly). Or that
    or each driver should come with some configuration file for every possible
    userspace daemon. BTW HOW userspace daemon should distinguish different drivers
    if there are neither major/minor numbers nor names ? If such names should
    appear in /dev without modifications is other story completely...

    TT> In any case, we're in feature freeze at this point, so this flame-fest
    TT> is a bit of a waste of everyone's time anyway. But as a path forward,
    TT> this is probably the best compromise and way to move forward. We may
    TT> still need to design a way for the kernel to talk to the user-mode
    TT> daemon, so that it's flexible enough to handle USB and whatever future
    TT> plug-n-pray buses come upon the scene, but that shouldn't be too
    TT> difficult, compared to the difficulties we've had coming to consensus.

    We should support not only brand-new plug-n-pray buses but also old devices
    like non IEEE whateveer-conforming printers (or IEEE-whatever conforming
    printers turned off while system bootup :-) printers and such. Where you just
    have no information about device before user first time tries to access it.

    TT> Then folks who like devfs sans a user-mode daemon can have much simpler
    TT> patches that do just that, and people who like to have a more
    TT> fully-featured user-mode daemon can do things that way. At that point,
    TT> though, I hope it will become clear to everyone that it's possible to
    TT> have a dynamic /dev directory *without* having the devfs component, and
    TT> folks will come to see that by having the minimal kernel hooks to allow
    TT> a user-space daemon, the result is cleaner, and in the long-run, allows
    TT> us the flexibility to make the system much easier for the user to use.

    Looks like a plan :-)




    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:4.039 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site