Subject: Re: scsipi woes: can't call scsi command from kernel by ioctl?
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 08/30/2005 20:16:47
--FkmkrVfFsRoUs1wW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi Manuel,

On Tue, Aug 30, 2005 at 06:21:40PM +0200, Manuel Bouyer wrote:
> On Tue, Aug 30, 2005 at 06:10:46PM +0200, Reinoud Zandijk wrote:
> > So i'll prolly have to start coding IOCTL's for all 12+ them :-S Some of 
> > them could also be implemented in scsipi_ioctl.c for not all are nessisary 
> > only found on cd/mmc devices.
> 
> I would say that you should implement an highter levelo interface between the
> scsipi drivers and your code. I guess you need several of these commands to
> do one function, so I would expect that not that much IOCTLs would be needed.
> Maybe IOCTL isn't the right interface for that either.
> IMHO the UDF code should not know about the scsi commands at all, but rather
> have functionalities provided by the lower layers. That way, if some
> other filesystem code needs to have access to the same functionality, or
> we need to have UDF working with some non-scsipi media, this will make
> it possible.
> Also I guess we'll find some broken devices which need quirks, and
> scsipi can handle that.

Most of the commands i need for setup, though offcource read/sync/write 
needs to be done regulary. In my userland code i used a disc abstraction 
that inquired the drive and handled all the specifics on 
SCSI/ATAPI/disc/file devices. I could try to generalise it and to offer the 
information in a IOCTL with the modification in the cd strategy that if a 
certain type of media is found (CD recordables f.e.) the synchronise caches 
call is made on each switch from write to read. Without the sync the device 
won't accept read attempts (and certain other calls) possibly leading to a 
device lockout in situations where a cd writing program crases. If one is 
lucky the timeout is less than 5-10 minutes :-S but some devices just wait 
till bus/device reset.

I've thought about implementing a /dev/mmc* device that is specific for 
cd/dvd/bd recordables/rewritables since they are a special breed of 
critters quite different from normal cd-rom/dvd-rom. Seperating mmc devices 
from the generic `cd' devices also enables more targeted code to be 
written. Code could also be simplified. How to use the detection framework 
i haven't figured out yet though. What i've read indicates that Linux also 
split off mmc devices from the older legacy CD driver.

thoughts?
Reinoud


--FkmkrVfFsRoUs1wW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQxSiiIKcNwBDyKpoAQK77wgAu2xR5YRG9DdUS/txESJkJVXt84SvM6O8
gqOrM3A5qcpXbyFI9c23e1VPsmg5afx/Y2Ig8gF2Ytt/24vRu9rRkcDi+nindRqH
M3FSSzBuSeZF9nuSLzVm/km+8MIueFohZ/NI6b5M75zM1SmqkSOYfuHft2PpY2hU
CO8WUtT/3XkZzh+Fj6/Jz5bPlhEmY7ew9XjFurd7wUiGZYDbvizSfzC0RoiqPXg2
e7iYb+JsZsdIEJ2XOs4q8sak1wyUxAH6sg28gIr6DBPPaJQU+deonB/igIe5r7Vw
O4tXhbtYCPa8f67uOH0oDGSU8WUy/YCyhZ0qrCEgUFWgyTtxo1BOsQ==
=7aWr
-----END PGP SIGNATURE-----

--FkmkrVfFsRoUs1wW--