Re: Scsipi guru needed...

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Dec 07, 2008 at 10:37:20PM +0100, Reinoud Zandijk wrote:
> > 
> > When you say "MAXPHYS should be fixed anyway" what exactly do you have in
> > mind?  Both endpoint devices and the buses they're on can have maximum
> > transfer size constraints, so some kind of inheritance scheme is needed;
> > and that looks to me (and to others who've looked at it, I believe) like
> > a considerable amount of work.
> 
> Considerable indeed. What i envisioned some time ago was a buffer system that
> has scatter/gather integrated with arbitrary lengths. That would simplify
> genfs code and the likes to a lot.
> 
> Maybe replace the buffer code with uiomove(9)/mbuf(9) analog code?

That would help, but the upper layer needs to be aware of the
limits of the driver or hardware anyway, isn't it ?

> 
> One could (also) create a system where the FS asks the destination drive for
> the maximum size it can transfer. By making it a vnode op, this size can be
> trimmed down by whatever bus or drive code comes by.

I had more something like that in mind. 

> 
> > Of course SCSI disks can take *very* large transfers.  But most systems
> > you can put SCSI disks on have other peripherals that are much, much
> > less accomodating; and some impose arbitrary restrictions on DMA transfer
> > size etc which will cause problems for _some_ ways you can attach SCSI
> > disks but not others.  Ugh.
> 
> The specific SCSI driver could when called by the call on the device vnode
> adjust the size to the devices recommended size and/or let scsipi limit it by
> the bus it is connected to say by the bus_space_* code.

Yes. Also note the value won't move over time, so it can be cached at
the vnode level.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--