[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Scsipi guru needed...
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.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |