On Tue, Aug 30, 2005 at 06:10:46PM +0200, Reinoud Zandijk wrote:
> I'm planning of at least implementing and using the following SCSI/ATAPI 
> commands :
> 	TEST UNIT READY			(trivial)
> 	MODE REQUEST/MODE SELECT page 5 (CD recording parameters)
> 	MODE REQUEST/MODE SELECT page 3	(CD-MRW/DVD+MRW address space)
> 	SYNCHONISE CACHE		(nessisary for swich r/w)
> 	CD READ RECORDED CAPACITY
> 	GET CONFIGURATION (0x46)	(for several features)
> 	READ DISC INFORMATION (0x51)
> 	READ TRACK INFORMATION (0x52)
> 	READ TOC/PMA/ATIP format 2	(nessisary for CD/DVD-ROM drives or old pre-MMC drives)
> 	READ/WRITE			(prolly/hopefully possible trough bread/bwrite)
> 
> and optional :
> 	SET CD SPEED (0xBB)
> 	CLOSE SESSION
> 	CLOSE TRACK
> 	REPAIR TRACK
> 	RESERVE TRACK
> 	WRITE AND VERIFY
> 	READ/WRITE				(with streaming bit)
> 
> For UDF reading/writing on non CD/DVD/BD i.e. on files, harddiscs or 
> floppies etc. access to bread/bwrite and a method of detecting the size of 
> the partion/file and *its sector size* is enough using f.e. 
> disklabel/wedge/stat info. UDF disc sector sizes are all multiples of 512 
> bytes though 2048 is very common.
> 
> Esp. `get configuration' can be lengthy if implemented by IOCTL for the 
> structures have to be made for most of the features for completeness though 
> in my implementation just being able to see if a feature is current or not 
> reveals normally enough. This is media type detection and accompanied 
> features like does it have RMW or can i only write in ECC blocks of 
> (normally) 32 sectors, do i have to synchronise caches before being able to 
> read again etc. etc.
> 
> 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.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--