Hi,


On Tue, Aug 30, 2005 at 08:16:47PM +0200, Reinoud Zandijk wrote:
> > scsipi can handle that.
> 
> Most of the commands i need for setup, though offcource read/sync/write 

Note that we already have IOCTLs for synchronise cache. Maybe you could
reuse that ?

> 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.

Yes; I think we should also allow writing though the raw or block device;
so we could allow writing using e.g. dd (instead of writing only though
the UDF filesystem).

> 
> 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.

How much code would this represent ? I don't know if it's really
worth it, and /dev/mmc vs /dev/cd could be confusing for users (not counting
the third-party packages that would need to be adapted to use both :)

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