[EMAIL PROTECTED] wrote:
>
> >From [EMAIL PROTECTED] Sat Apr 1 18:14:22 2000
>
> >A recent posting on the SANE newsgroup reported the "scsi_info"
> >program failing. A cause for this failure on a recent 2.3 series
> >kernel is that the SCSI_IOCTL_GET_IDLUN ioctl made available
> >by the SCSI mid-level code (and hence to all scsi device
> >file descriptors) has changed. The cdrecord application is
> >also effected by this change.
>
> >> "four_in_one" is made up as follows:
> >> (scsi_device_id | (lun << 8) | (channel << 16) | (host_no << 24))
> >> These 4 components are assumed (or masked) to be 1 byte each.
> >>
> >> The 'host_no' element is a change in lk 2.3/2.4 kernels. [In the lk 2.2
> >> series and prior it was 'low_inode & 0xff' of the /proc pseudo file system
> >> entry corresponding to the adapter/host.] This change makes the use of the
> >> SCSI_IOCTL_GET_BUS_NUMBER ioctl superfluous.
>
> As cdrecord only uses this number to have one more criteria to do the mapping,
> I would assume that cdrecord will work as before.
>
> Did you definitely observe problems?
No, I was just aware that the libscg code used it. Best that
you know about it.
BTW Several failures of cdrecord have been reported on the
linux-kernel newsgroup using 2.3.99-pre* . As far as I could
see they are associated with the change that makes shm a file
system and those people not mounting it.
Also the device pseudo file system (devfs) can make a real
mess of apps that scan for sg devices although in cdrecord's
case the /dev/cdroms subdirectory looks promising. Luckily
devfs is optional and it will be a brave distribution that
first makes it the default.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
