On 1/31/06, Joerg Schilling <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > Joerg, I don't see any sense in providing users with fake SCSI
> > lun and bus numbers for ATAPI devices. I think that what users
> > would like is the list of devices consisting of "fd" and actual vendor
> > name of device (+ optionally serial no + optionally "x:y:z" for real
> > SCSI). Nobody wants to see some artificial "x:y:z" for her/his
> > ATAPI device (it has always annoyed me in Windows), not to say
> > that the majority of desktop users have absolutely no idea of meaning
> > of these numbers.
>
> This is called integration and it is done by Linux e.g. for 1394 and USB SCSI
> devices. So why not for ATAPI?
Because we have native drivers which do not require SCSI stack et all.
> > * ide-* drivers for ATAPI devices are needed (some devices just doesn't
> > work with ide-scsi ATM) so please accept this fact that we cannot just
> > now simply switch over everything to using ide-scsi and we have to use
> > SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
> > support for it). I'm not saying this won't change in future but this requires
> > doing actual work and people seem to be more interested in discussing
> > stupid naming issues than doing it so...
>
> Well, the problem with ide-scsi is not a general one but caused by a simple
> bug that needs to be fixed.
Please _reread_ this paragraph:
* some devices (not cd-writers) doesn't work with ide-scsi
* they require quirks which are in ide-cd so it ide-cd needs to stay as a driver
* if is very useful if cd-writing can be done with ide-cd and without SCSI stack
(a hack but very useful one)
[ more below ]
> > > If the Linux folks could give technical based explanations for the questions
> > > from above and if they would create a new completely orthogonal view on SCSI [*]
> > > I had no problem. But up to now, the only answer was: "We do it this
> > > way because we do it this way".
> >
> > The answer is - we do this this way because of historical reasons and we
> > simply lack resources to change it immediately (be it your "everything is
> > SCSI" or mine "block layer devices claiming supported transport types").
>
> This is obviously not true: There _was_ (and still is) a useful implementation
> with minor bugs. But instead of fixing the minor bugs, a lot of work has been
> done to introduce a new and unneded new interface.
>From technical point of view:
pros:
* you don't need SCSI stack (a lot of code saved!)
* you use subsystem native driver (a lot of complexity with locking
etc avoided!)
* you don't need to provide users with fake data (SCSI lun and bus)
cons:
* user-space applications need to support it
What are the _technical_ problems with SG_IO interface besides
issue with enumaration of devices available in the system?
I know that you don't like SG_IO but it is hardly technical argument.
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]
