J. Hannken-Illjes 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 compatible.
--
Emmanuel Dre
On 26 Oct 2014, at 17:55, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes 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 c
J. Hannken-Illjes 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 wanted operation, in which
On 26 Oct 2014, at 08:46, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes 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.
What happens when l
J. Hannken-Illjes 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.
Right.
> - Are you sur
On 26 Oct 2014, at 03:52, Emmanuel Dreyfus wrote:
> Chuck Silvers 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 before it does any good.
