> >> Background:
>
> >> Ideally struct buf should have had a real OO like operations vector
> >> like vnodes have it, and struct bioops is the first step towards that.
> >>
> >struct buf will eventually become merely an iocmd structure, so why do
> >we want to complicate things here?
>
> No, struct buf will remain the cache-handle. the iocmd is called
> struct bio.
>
Even if struct buf stays around, its cache-handle role will be diminished,
probably just a translation layer to vm object based caching.
> >We already have an OO method for bwrite: VOP_BWRITE(), the problem
> >is most of the code are still calling bwrite() directly. Will it
> >solve your problem if we change every bwrite() into a VOP_BWRITE()?
>
> Well, I'm not sure it is correct to go the detour around Vnodes,
> if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those
> other operations as well.
>
Don't you need bp->b_ops->bawrite(), bp->b_ops->bdwrite() as well?
I feel it's better to go through the vnode, because for all the bufs
belong to the same vnode, these b_ops are most likely to be the same.
And for a stackable filesystem, you may easily implement a passthru
call with vnode, how would you deal with it using struct buf?
> But what vnode would you use for a buffer associated with a freeblock
> bitmap ?
>
Each buffer belongs to a vnode, a buffer associated with a freeblock bitmap
belongs to the device vnode, and that's the vnode we could use.
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
