It seems Peter Wemm wrote:
> > Well, CAM & ATAPI is "fairly" easy, the only problem being all the
> > little details that are different enough to make it non-trivial to
> > maintain. I once sat down and tried to get all the details on how
> > the CCB's where different, and decided that I wouldn't want to engage
> > in that.
> > Another story is ATA disks, there you either have to teach CAM about
> > a new lowlevel protocol, or write a SCSI<>ATA translator, which I
> > also decided I didn't want to do...
>
> Well, that's assuming you use scsi ccb's... you could use atapi ccb's.
> We have cam/* which is the generic transport handler. cam/scsi/* which
> is the scsi peripheral drivers that use scsi ccbs, and then we could
> have cam/ata/* which uses atapi ccb's and ata disk info. Then you have
> cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code
> then gets requests sent to it in atapi format and/or something suitable for
> ata disks.
>
> This approach is quite efficient and you get to use the common queueing, error
> recovery, etc etc stuff. You don't have to do ccb translation or anything.
> You get your own disk, tape, cd etc driver with their own names and major
> numbers. They would look *very* similar to the scsi counterparts but would
> be seperate as they use different ccbs, different backend-specific hooks, etc.
Uhm, yes, agreed, but it defies some of the gains (ie common highlevel drivers)
but would probably keep the performance of the current approach. It would
make life a wee bit less complicated, but one would still have to do all
the lowlevel code to deal with queing etc, but the higherlevel stuff
could probably be shared, maybe CAM would have to be modified a bit
but it should be possible...
> Things like umass, vpo etc have it easy since they basically bulk send the
> scsi ccb's to the device as they use the scsi protocol directly. The ATAPI
> protocol is similar but would require translation if it used the common top
> end drivers. So, it either requires different top end drivers or has to do
> translation.
So its basically a choice between added complexity or added complexity :)
When I get all the lowlevel stuff done (this has to be done no matter
what approach is chosen) I'll take a look at it again, but if anybody
feels like doing anything about it, let me know, so we can get things
coordinated....
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
