Subject: Re: scsipi woes: can't call scsi command from kernel by ioctl?
To: None <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 08/30/2005 22:07:09
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 <firstname.lastname@example.org>
NetBSD: 26 ans d'experience feront toujours la difference