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

Dear folks,

scouting filingsytem for details about filingsystem/UBC interaction puzzles 
me. There seem to be several methods used for VOP_READ/VOP_WRITE 
interaction to UBC:

- no visible interface, like smbfs, ntfs
- explicit ubc code snipped like used for ffs, nfs, cd9660, filecore, 
  msdosfs, adosfs:

      win = ubc_alloc(&vp->v_uobj, uio->uio_offset, &bytelen, UBC_READ);
      error = uiomove(win, bytelen, uio);
      flags = UBC_WANT_UNMAP(vp) ? UBC_UNMAP : 0;
      ubc_release(win, flags);

Would that mean that smbfs and ntfs do not use the UBC? or does that simply 
mean they don't use the mmap semantics of the vop_getpages, vop_strategy 
path but rather use the older read/write buffers?

from the man-page:
     ubc_alloc() creates a kernel mappings of uobj starting at offset offset.
     the desired length of the mapping is pointed to by lenp, but the actual
     mapping may be smaller than this.  lenp is updated to contain the actual
     length mapped.  The flags must be one of
     ...

     ubc_alloc(struct uvm_object *uobj, voff_t offset, vsize_t *lenp, int
     flags);

Can i to force a certain buffer length to be passed in calls to 
VOP_STRATEGY() use this parameter `*lenp' passed to ubc_alloc() ? or is it 
just trunced to the nearest page size?

Cheers,
Reinoud


--ADZbWkCsHQ7r3kzd
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBQxhkbIKcNwBDyKpoAQJA3wf/ae1Fik2qIwnenTYJq0HJqpIHM+Wlg7Qu
aobjGcqjZ030CHSmnfAhA3oorRcAdJF94rHDDN398J99WzoCv+XviB3F4WvEINXN
9uhEzH3wthIluftNmfh4fpfsCF2waf/32PG/qlk8HPdwatRSEehwRoifyh3ZmMe1
SQAxLB2EipQ+f8Ce8kDgL2y1rfuUzsLJMqqXsmjTrQuPgIgyJ6pMqr6OIj4ny4yL
K3QORm8Zu5T/8/YU8BCgkpaWg6XkyC5ckmDH29MVgkkF0i2jK5o/yV8+jVl3zZTC
wGi3NqdukfV399fEtZEn8kkeZ2bRl5aWYUbUDql1x688+EnDp2ZNqg==
=T5lb
-----END PGP SIGNATURE-----

--ADZbWkCsHQ7r3kzd--