[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: UUIDs (and devfs and major/minor numbers)
    On Thu, Jun 17, 1999 at 12:49:47PM -0400, Horst von Brand wrote:
    > DAVID BALAZIC <> said:
    > > An opinion about /dev :
    > >
    > > In the old system /dev is a collection of "links" from
    > > filenames to device numbers (major:minor).
    > >
    > > With devfs it could be a collection of links from
    > > filenames to /devfs/* entries.
    > By whom/how are permissions handled? Even if it's symlinks, the original
    > files in /devfs have to carry them (you can't follow symplinks to files you
    > can't access directly!). And that means the kernel has to know how to set
    > up permissions for a new device when it appears, and remember the settings
    > from one boot to the next. Gross. And a kludged initscript that sets them
    > up on each boot is even worse. As bad as the much-maligned MAKEDEV, but run
    > _each_ boot, so much more critical.

    The solution is an /etc/devfs.conf which sets perms/uids/gids against node
    names. The format being something simple like

    /dev/sd/* 0660 root disk
    /dev/sg/* 0660 root sys

    If accesses to the devfs /dev then communicate with devfsd to create nodes
    then node creation is in user space so perms can be setup properly.

    This isn't as "unix-like" as using chmod directly on the node, but I can't
    see a more elegant way of doing it while retaining a virtual /dev.

    Anyway I hate the tarball hack, so /etc/devfs.conf appeals to me.

    In fact seeing as MAKEDEV currently implements something rather similar to
    /etc/devfs.conf anyway, it's not that much of a change.

    And having a virtual /dev is most of the point of having devfs.

    I would like a devfs mounted on /dev which does nothing except report node
    accesses that ENODEV to devfsd. Then devfsd can implement all the policies
    and naming schemes. Permissions can be handled with /etc/devfs.conf (which
    I think is neater than chmod in an ext2 based /dev anyway). The devfsd can
    be responsible for node creation with mknod(). Module insert/remove events
    can also report to devfsd, preferably with major/minor numbers, so that we
    could shove even more policy in devfsd. So perhaps a revised devfs.conf

    14 3 /dev/dsp 0660 root sound

    With major and minors in the first two columns. This would make all policy
    exist in user space. The only thing the module needs report to devfsd is a
    major/minor pair. Persistence is assured because devfs.conf is stored in a
    file in /etc which is on ext2. You still have a fully virtual /dev. And it
    is also possible to access non-existant nodes and have devfsd lookup names
    instead of major/minor numbers to create the node properly. Accessing node
    names or major/minor pairs which aren't listed in devfs.conf just fail.

    This makes sense to me, and I think moves all policy that Tso and HPA have
    been unhappy about completely into a userspace devfsd. I also think it has
    the least impact on the existing functionality of devfs (you lose creation
    of nodes which don't have devfs.conf entries which might upset proprietary
    module developers, but that's about it). It also doesn't meet the proposal
    by Tso of providing bus/lun/id information, but I'm not sure that's really
    a /dev issue anyway (sounds more like a /proc/hardware/ issue).

    Is this a fair compromise between devfs/nodevfs parties? I really would be
    happy if devfs made it into 2.3 but the current stalemate isn't getting it
    anywhere quickly. I can understand that virtual /dev isn't traditional but
    traditional UNIX /dev really can't handle kernel modules and hot pluggable
    hardware properly. I'd be most interested in hearing HPA and Tso's opinion
    on this scheme.

    Nathan Hand - Chirp Web Design - - $e^{i\pi}+1 = 0$
    Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail:

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.030 / U:125.912 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site