On 26 Oct 2014, at 03:52, Emmanuel Dreyfus m...@netbsd.org wrote:
Chuck Silvers c...@chuq.com wrote:
but more fundamentally, since puffs code cannot prevent changes to the file
in the underlying fs (ie. changes that don't go through puffs), any
preallocation done by puffs can be undone
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
- Increment PUFFSVERSION.
When is it really required? Without incrementing it, a newer kernel
works with an older libpuffs, but if I increase it I get an error about
version mismatch.
- You should recover the error in puffs_vnop_close() too.
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
What happens when libpuffs receives an unknown message (fallocate in
this case)?
The filesystem using libpuffs tells the kernel what operations should be
sent to userland when it calls puffs_init(). It can be done
- by setting the list of
On 26 Oct 2014, at 17:55, Emmanuel Dreyfus m...@netbsd.org wrote:
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
What happens when libpuffs receives an unknown message (fallocate in
this case)?
The filesystem using libpuffs tells the kernel what operations should be
sent to userland
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
Since it was last incremented at Rev. 1.72 many messages got additional
fields so the version should be incremented independent of your change.
What messages are you referring to? Each time I added something it was
meants to be backward
