Re: [Libcdio-devel] [Patch] More bullet-proof drive detection for GNU/Linux

[R. Bernstein]

First, thanks for changing those strcpy's to strncpy.

Am I missing something or would "PATH_MAX" better be "len" below? 

    else {
      tmp_dst[len] = '\0';
      strncpy(tmp_src, tmp_dst, PATH_MAX);
    }

As for the rest, well, as I said I'm a back-seat driver here. I'm
hoping others will offer their expertise. The question I have is how
pervasive hal, /sys, and /proc/{ide,scsi} are across different OS's
and installations. And as you said how reliable they are. 

It is possible that to make hal an optional dependency, if needed.

Burkhard Plaum writes:
 > Hi,
 > 
 > [...]
 > > As a back-seat driver, here are my thoughts as to why /sys or
 > > something like that is better. The problem with scan over a fixed
 > > number of device numbers is that you never can get the number right:
 > > either you are not scanning enough *and* on average the program is
 > > scanning too much.
 > 
 > Ok, that's right.
 > > 
 > > We received one comment that you really can't tell what the highest
 > > SCSI device number would be. And right now it's set probably higher
 > > than what most computers in fact have. So time spent in testing for
 > > devices that don't exist on most computers, while still not being
 > > thorough.
 > 
 > Also agree. For each nonexistent device, we do a stat() call (called
 > from cdio_is_device_generic()). Don't know how much time is wasted by this.
 > I didn't notice a slowdown by the new method here, but must admit, that
 > I tested it only on pretty fast machines.
 > 
 > So what are the alternatives?
 > 
 > - opendir("/sys/block") and scan it:
 >    Each block device shows up as a subdirectory here (probably the best
 >    method if /sys/ exists).
 > 
 > - opendir("/dev") and scan for major numbers:
 >    Probably prossible for udev enabled kernels, would be awfully slow for
 >    pre 2.6 kernels with their 1000s of unused device nodes.
 > 
 > - opendir("/proc/ide"), opendir("/proc/scsi"):
 >    Maybe worth a try, but I don't know how reliable that is
 > 
 > - Talk to hald: No idea how this works (would add some dependency to libcdio)
 >    but "lshal | grep block.device" at least shows:
 > 
 > lshal version 0.4.7
 >    block.device = '/dev/hda1'  (string)
 >    block.device = '/dev/hda2'  (string)
 >    block.device = '/dev/hda3'  (string)
 >    block.device = '/dev/hda4'  (string)
 >    block.device = '/dev/hda'  (string)
 >    block.device = '/dev/cdrom'  (string)
 >    block.device = '/dev/cdrom'  (string)
 > 
 > In any case, the routines needs to try several methods.
 > 
 > [...]
 > > Recommendation such as to use strncpy over strcpy is precisely because
 > > the world has gotten so that you can't trust anything anymore: if
 > > there's a way to subvert a program someone will make use of it.
 > 
 > Ok, I increased the sizes of the 2 arrays by 1 and replaced all strcpy by
 > strncpy.
 > 
 > Burkhard
 > 
 > 
 > _______________________________________________
 > Libcdio-devel mailing list
 > address@hidden
 > http://lists.gnu.org/mailman/listinfo/libcdio-devel
 >