hi,

> > > 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.
> > 
> >   That sounds rather awkward, at least from a user's point of view.  I
> >   want it to be as simple as
> > 	$ pubconfig pub0 pub-server-program args
> 
> Sure, but you're considering the case of the userspace process dealing
> with a particular file format, like .dmg or vmware .vmdk.  That's a
> fine idea, at least for file formats that aren't suitably represented
> as a filesystem (like archives).

  Well, for archives, we have puffs/fuse, so no need to support those
with the pub (pass to userland blockdevice) too.

> The counterpoint is that people might want to host vnd files on all
> kinds of filesystems, perhaps often on network or replicated
> filesystems; you don't want to be writing the network or replication
> code twice, once for vfs and once for vnd.
> 
> Of course, you should be able to do both, one on top of the other, if
> it makes sense.

  I don't quite understand.  Do you mean the file they want to use as
the vnd image is on a replicated/network file system?  If so, I'd
expect the user to use a file system to access that file, but that's
orthogonal to the format of the file and accessing its contents.

> > > 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).
> > 
> >   Yes, that's pretty much what I had in mind.
> 
> Beware of another limitation: the block layer is basically
> asynchronous, so your userspace process needs to deal with many
> parallel requests.  That's fine for the "remote-vnd" interface, but it
> also applies to the userspace process's access to the underlying file,
> once it's done its translation work.  Parallel Async IO to a file from
> userspace is currently not especially pretty (there's no AIO, so
> you're pretty much stuck with the hassle of using lots of threads).

  Hm, that's bad.  Maybe I'll simply add DMG support directly in the
kernel and revisit pub when we have AIO.

					yours,
					dillo