[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Burkhard Plaum
Subject: Re: [Libcdio-devel] [Patch] More bullet-proof drive detection for GNU/Linux
Date: Tue, 28 Nov 2006 14:39:30 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]