On Fri, Feb 23, 2007 at 02:40:56PM +0100, Reinoud Zandijk wrote:
> Dear folks,
> 
> i've been fighting struct buf{} again and really the whole buf system needs 
> a spanking... its uses are so diverse and its getting such a clutter IMHO. 
> This time i was bitten by the fact that biodone() unlike physio() doesn't 
> use a workqueue and gets called from interrupt context(!)
> 
> Would it be good to inventarise the uses of struct buf and come up with a 
> more clean solution? I've seen it use for :
> 	- buffer cache, i.e. caching data
> 	- passing of data to device driver
> 	- using the B_CALL as initiator of new actions when one finishes 
> 	  (cgd f.e.)
> 	- splitting up a request using nestiobuf() (and B_CALL)
> 	- providing a vehicle to have multiple callbacks/contexts using 
> 	  nestiobuf's B_CALL
> 	- counting of pending actions
> 	- ....
> 
> I think its better to split the functions up:
> 	- buffering of metadata (also proven to work fine with UBC (see 
> 	  UDF))
> 	- passing of data to drivers (getiobuf() was initial start of this)
> 	- nested buffer for splitting up a request.

I'd also like to have requests aggregations (e.g. raidframe can issue
multiple contigous buffers, the drive would be happier with a single large
I/O than multiple smalls)

> 	- all finished bufs ought to called back on a kthread (workqueue 
> 	  like in physio())
> 	- call back queueing, a TAILQ() of functions with private data 
> 	  pointer? with an abort function to prevent further calling?
> 	- adding of pending/finished callbacks counters? (clustering of 
> 	  reads/writes)
> 	- .....

I think this would be good. The new design should also take in account
I/O to unmapped memory (it's not needed to have the buffer mapped in kernel
VM space to do a DMA transfers on behalf of a userland program). This would
probably remove the requirement that a buffer points to a contigous VM
region (when mapped), which is annoying when building buffer requests.

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