Re: [PATCH] [RFC] fsnotify: Tell the user what part of the file might have changed

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Tvrtko Ursulin
Date: Monday, November 15, 2010 - 3:57 am

Hi Pete,

On Monday 15 Nov 2010 00:44:08 Alexey Zaytsev wrote:

Looks like a potentially useful feature. For now just some implementation
comments below.


Since existence of range metadata is determined by fsnotify it would be nice
if fanotify had no knowledge of when it will be present but could just check
for its presence. But I do not feel that strongly about this. Especially since
more important issue is the packet protocol. More on that later.


#ifdef CONFIG_FSNOTIFY?


This does not look extensible. Imagine you add another optional data to the
union which has the same size - how would one distinguish between the two?

I think the original idea for protocol extensibility was to use the version
field. Optional sub-packets were not considered, but if we now want to add
them we should do it right. For example more than one optional data packet
could also be something which appears in the future.

But for this particular feature, maybe you could get away with bumping the
protocol version and always carrying the range fields? Just as long they are
sanely initialized if not applicable it could be fine.

Also you would need to document what is end. Is it the last modified offset or
one after? Looks to be the latter in the current implementation.


Again end needs to be documented.


Could you somehow get rid of this conditional?

On close you can pass -1 as u64 to userspace anyway so maybe min with unsigned
values would work?


Max with start or end here?

Tvrtko

Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] [RFC] fsnotify: Tell the user what part of the ..., Tvrtko Ursulin, (Mon Nov 15, 3:57 am)