[Debburn-devel] -header:Cc:we at x-net.at

[Thomas Schmitt]

Hi,

Wolfgang Eibner wrote:
> https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/388436
> drives [...] connected via a ide <-> firewire changer. 
> [...] turn it on again, the scsi busno is increased by one.
> [...] can lead to very high numbers like 277

I experienced a similar effect with USB memory
sticks which inflate the bus numbers by frequent
re-plugging and newly plugged USB DVD drives
which then get high bus numbers.

My program cdrskin had sharper restrictions on
bus numbers than cdrkit. It was necessary to
change the way of listing busses and their
devices.
To my luck this only affected the emulation of
-scanbus and not the other operations of libburn.


> Is it really a kernel issue or is it an issue
> of cdrkit (wodim/cdrecord/...) cause it has a
> maximum value while the kernel has none (only
> at overflow)? 

It would be interesting to find out whether the
kernel has a noteworthy upper limit for SCSI bus
numbering.

Nevertheless, the bus number is not essential
for a burn program on Linux. We have no way to
address a drive via that number but must open
device files and can only then detect their
bus adress tuple Bus,Target,Lun.
After that, we are free to implement poor sorting
algorithms resp. data base structures.

-------------------------------------------------

I hope the cdrkit team does not mind if i
propose Wolfgang to try whether cdrskin-0.6.7
(the current development version) can cope
with his bus numbers.
It is intended as replacement for wodim resp.
cdrecord:
  http://scdbackup.sourceforge.net/cdrskin-0.6.7.tar.gz

See also
  http://scdbackup.sourceforge.net/cdrskin_eng.html
Make sure _not_ to test the release version
cdrskin-0.6.6 where -scanbus lists no bus above
15 (but elsewise works fine with such drives).


Have a nice day :)

Thomas