# 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..."
  - Previous message: Jason Joy: "Problems with UMAX, think I'm missing something elementary..."
  - In reply to: Joe Smith: "Re: Permissions of /dev/sg* and xsane, xscanimage (was Re: Report on , last CVS snapshot)"
  - Next in thread: Petter Reinholdtsen: "Re: Report on last CVS snapshot"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  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

  - Next message: Douglas Gilbert: "Re: Problems with UMAX, think I'm missing something elementary..."
  - Previous message: Jason Joy: "Problems with UMAX, think I'm missing something elementary..."
  - In reply to: Joe Smith: "Re: Permissions of /dev/sg* and xsane, xscanimage (was Re: Report on , last CVS snapshot)"
  - Next in thread: Petter Reinholdtsen: "Re: Report on last CVS snapshot"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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