Re: Permissions of /dev/sg* and xsane, xscanimage (was Re: Report on , last CVS snapshot)

From: Douglas Gilbert (dgilbert@interlog.com)
Date: Thu Feb 24 2000 - 20:10:23 PST

  • Next message: Douglas Gilbert: "Re: Problems with UMAX, think I'm missing something elementary..."

    Joe Smith wrote:
    >
    > Peter Hackenberg <phackenberg@aip.de> wrote: [ mod my snips ]
    > > Given that under "regular" conditions, i.e. all scsi devices are
    > > switched on at boot time, ... and you reboot with the scanner switched
    > > off, then /dev/sg2 points to the sensitive device.
    > > ...
    > > The "obvious" solution to give the "sensitive device" a lower scsi number
    > > than the scanner is not feasible if that device must have a higher
    > > priority. It also fails if you dynamically load/delete scsi devices.
    > >
    > > I do suggest to eliminate the /dev/scanner symlink business totally,
    > > because it is not unlikely that it points to the wrong device.
    >
    > The root cause is that SCSI device names are assigned dynamically,
    > which is well understood to be a Bad Thing and will go away at some
    > point. Once scsi device names are based on the host.id.lun, this
    > won't be a problem. Obviously, this doesn't help now.

    People may be interested in knowing that devfs was accepted into
    the linux development kernel 2.3.46 (after a gestation period of
    2 years). This means it will be in the 2.4 release series.

    So lets assume you have a scanner on scsi host 0, bus 0, scsi_id
    4 and lun 0. Then with devfs and its daemon (devfsd) running in
    full backward compatibility mode you will have:
    /dev/sg0
    /dev/sga
    /dev/scsi/host0/bus0/target4/lun0/generic *
    /dev/sg/c0b0t4u0
    [/dev/generics/generic0]

    to choose from. The actual device "mknod" is found at the long
    path name marked with *. All other entries are symbolic links
    to the actual device and these links are maintained by devfsd
    (which is configurable). The author of devfs, Richard Gooch,
    is thinking about adding the last entry (shown in square
    brackets) and he would like to see the first 2 dropped. My
    guess is the major distributions will have the last word on
    that issue. Note there is no /dev/scanner entry. There is
    nothing in the devfs tree that tells you which type of scsi
    device you've got (but if you're really cunning an algorithm
    could deduce this my process of elimination .... its' not
    a disc, nor a tape ...). You can find out the scsi device
    type by looking in /proc/scsi/sg/devices (also new in 2.3).

    BTW The IDE naming scheme is similar to the scsi scheme
    (with "scsi" replaced by "ide" in the long path name). Not
    sure about the USB, parallel and firewire naming schemes.

    The really good thing about devfs (in its native state) is
    that you only get entries for what is found on your system
    at boot time or later loaded by module. Compare this with
    the 5000+ /dev entries on a typical RH 6.0 system.

    Doug Gilbert

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
    



    This archive was generated by hypermail 2b29 : Thu Feb 24 2000 - 20:05:27 PST