Hi,
I'm stealing thread in hope of stopping flamewar
and finally having some useful discussion.
I address this to everybody not only to Joerg:
[*] As this is my thread now discussing SG_IO on /dev/hd* vs /dev/sg*
is BANNED. Please continue discussing this in the old thread. :-)
I'm sure thare are other important things that we can agree on.
If it doesn't work it will be my first and the last mail in this thread...
On 1/27/06, Joerg Schilling <[email protected]> wrote:
> Vojtech Pavlik <[email protected]> wrote:
>
> > > The only integrative (and this useful for libscg) interface on Linux is /dev/sg*
> > >
> > > /dev/hd* may look nice if you only look skin-deep
> > >
> > > How do you e.g. like send SCSI commands to ATAPI tape drives on Linux?
> >
> > I see you asking this again and again, and you seem to want to hear this
> > answer: "You don't." I haven't checked the code, but I guess the SG_IO
> > interface isn't available there. And I don't think this is a problem,
> > because a) if it was needed, it can be added trivially with minimum
> > added code, b) ATAPI tapes are dead, much the way ATAPI floppies are.
>
> Nice to see that agree that sending SCSI via /dev/hd* is a hack with limited
> benefit.
>
> Maybe (now that we did agree about the way to go) it makes sense to start
> discussing which bugs in Linux need to be fixed in order to close e.g.
> the Bugs in the Debian bug tracking system for cdrtools that are related to the
> Linux kernel.
Yes, lets talk about other problems, do you have pointers bugs handy?
I'm not very familiar with Debian bug tracking system and I see there
more than 3 bugs for cdrtools.
> This are the three most important Linux kernel bugs:
>
> - ide-scsi does not do DMA if the DMAsize is not a multiple of 512
> A person who knows internal Linux structures shoule be able
> to fix this (and allow any multiple of 4) in less than one hour.
I'll take a look, it should be quite easy
and I don't see a reason for this restriction.
> If we sum up the time spend on this discussoion, I really cannot
> understand why this has not been fixed earlier.
Because nobody cared and flamewaring is easy in contrast
to doing some real work.
> - /dev/hd* artificially prevents the ioctls SCSI_IOCTL_GET_IDLUN
> SCSI_IOCTL_GET_BUS_NUMBER from returning useful values.
> As long as this bug is present, there is no way to see SG_IO
> via /dev/hd* as integral part of the Linux SCSI transport concept.
What are the return values of SCSI_IOCTL_GET_IDLUN
and SCSI_IOCTL_GET_BUS_NUMBER needed for?
Please elaborate as:
* SG_IO ioctl doesn't require lun and bus number for arguments
* sg_io_hdr_t also doesn't contain/require these fields
so I simply cannot see why they are needed by kernel.
If lun and bus number are needed by cdrecord please explain why
(if only for enumerating devices sorry but see [*]).
> - If sending SCSI sia ATAPI, Linux under certain unknown conditions
> bastardizes the content of SCSI commands. A possible reason may be
Sorry but I can't do much about it without knowing more details.
Please provide some way to reproduce the problem
("certain unknown conditions" is not very useful).
> that it sends random data in the remainder between the actual
> SCSI cdb size and the ATAPI SCSI cdb size.
It should send 0-s but I'll recheck this.
> ATAPI drives that verify SCSI cdb's for correctness fail in this
> case.
Thanks,
Bartlomiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
