On Jan 4, 2006, at 5:15 AM, Reinoud Zandijk wrote:

> Also in the example i'm refering to descriptors (inodes) and other  
> meta
> information that is read in from the disc. Its part of the vnode's  
> v_data.
> Such information could be stored in buffers with a B_LOCKED but  
> that would
> be abusing the bio cache.

So, you're reading a structure from disk and storing it directly in  
the udf_inode (or whatever you call the v_data structure)... I guess  
that's one way to do it... UFS does it a different way... it bread 
()'s the data, then copies the data from the on-disk representation  
into a (more convenient) in-core representation, possibly byte- 
swapping it.

Anyway, what you're really looking for is "struct buf as an I/O  
descriptor".  Lots of parts of the kernel do what you're doing  
already.  They don't use getbuf() / brelse() at all.

Some of them do this:

int
dkwedge_read(struct disk *pdk, struct vnode *vp, daddr_t blkno, void  
*tbuf,
     size_t len)
{
         struct buf b;

         BUF_INIT(&b);

         b.b_vp = vp;
         b.b_dev = vp->v_rdev;
         b.b_blkno = blkno;
         b.b_bcount = b.b_resid = len;
         b.b_flags = B_READ;
         b.b_proc = curproc;
         b.b_data = tbuf;

         VOP_STRATEGY(vp, &b);
         return (biowait(&b));
}

Some of them dynamically allocate the buf from the bufpool using  
pool_get()/pool_put().

I don't see any reason to muddy the buffer cache waters anymore than  
they already are by adding B_MANAGED (or B_EXTERN or whatever).

Eventually, what we probably ought to do is break "struct buf" into  
two different types:

	struct bio -- This is the I/O descriptor.

	struct buf -- A "subclass" of "struct bio" that handles the caching  
aspects.

-- thorpej