--Vy1A5eXR7jld12ZH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Mar 09, 2007 at 12:25:01AM +0100, Dieter Baron wrote:
>   Or is it preferable to have the ability to pass block read/write
> requests to a vnd to a user land process, similar to what puffs does
> for file systems?

It might be (for efficiency or other similar reasons) but it shouldn't
strictly be necessary -- nor am I sure that it's the most
generally-useful model.

You should be able to use vnd with a file vnode backed by a puffs
filesystem (for example, encfs or lzofs).  vnd will turn the block ops
into vnops just as it does now, and puffs will forward the vnops.

There's a problem with this right now - it doesn't work because puffs
has a KASSERT about not getting B_READ|B_ASYNC requests, which vnd
issues (unconditionally) via the nestiobuf_* stuff in kern/vfs_bio.c.

I was chatting to pooka about this yesterday in the midst of other
things, and hopefully it'll be resolved soon, and we'll be able to
make use of all the other new kinds of vnodes puffs+fuse can give us
with vnd.

That being said, for specialised block-device-like formats, maybe a
pass-to-userspace block driver (not via vnd) would be useful too,
rather than going via vfs and back.  (ie, the operations passed would
be ops like strategy, start, .., from the block layer).

Perhaps "pud" (pass-to-user device) or "pub" (... block) or "pus"
(... strategy) ..

--
Dan.
--Vy1A5eXR7jld12ZH
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iD8DBQFF8LVzEAVxvV4N66cRAnEfAJ4z4ZktJlGx2jV04uWjJ2TER1SidQCeJlJP
8iME6o4Gxhumzeee9OD1Ycg=
=QPOX
-----END PGP SIGNATURE-----

--Vy1A5eXR7jld12ZH--