On Thu, 11 Jul 2002, H. Peter Anvin wrote:
> Erik Andersen wrote:
> >>
> >>Lovely. Let's make EACH APPLICATION support two disjoint APIs for no
> >>good reason.
> >
> > Lovely. Lets rip off a sarcastic answer without spending two
> > seconds to think. Why would anybody need to support two APIs?
> > The existing CDROM_SEND_PACKET ioctl is an ATAPI/SCSI pass
> > through interface, and is sufficient to operate both IDE and
> > SCSI cd writers.
> >
>
> That's fine, but it still only supports CD writers. We have a generic
> packet interface for a good reason -- we should be able to access it
> regardless of device type.
>
> It's a specific solution to a generic problem.
Nice, so you still have to strip and export to the transport layer.
Please expand on what you are going to talk to packetized and the
associated transport protocol restricted to the scope of storage.
Next count all the different personalitys associated with the discrete
transport layer.
If you are referring to Jens' pktcdvd interface out of block, it is no
more than a bypass of dealing with scsi. It would allow direct access to
the physical transport without portions of OS mucking up things as it does
now.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:21 EST