On 2009-11-26 at 20:02:12 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > > > So what do we agree on? > > > When using a live query, chances are very high that you want to > > > monitor > > > the file in question, anyway. Since the entry didn't change wrt the > > > query, I would find it cleaner to keep that separated. > > > Introducing B_ENTRY_MOVED would also require userland apps to > > > support > > > this (unlike my previous B_ENTRY_REMOVED/B_ENTRY_ADDED hack). > > I'm fine with the query flag to automatically start node monitoring. > > If we > > want to add the feature minimally invasively, we'd only add a new > > query > > flag just triggering B_WATCH_NAME watching on the concerned entry' > > node. > > The alternative would be to either squeeze the requested node > > monitoring > > flags into the fs_open_live_query() flags or add another call with > > separate > > flags. > > Thinking about it, live queries are almost useless without further > monitoring the file. > Maybe the B_ENTRY_REMOVED/B_ENTRY_ADDED work-around wasn't so bad after > all (ie. it could be made working better) - it could be the default > unless one specifically asks for monitoring the results automatically. Yeah, let's drop the automatic node monitoring idea. Instead I would introduce a live query flag indicating that the application wants a B_ENTRY_MOVED notification. If the flag is not set it will get B_ENTRY_REMOVED+B_ENTRY_CREATED instead. In the kernel introduce a notify_query_entry_moved(), that besides the obvious parameters also gets the flags passed to open_query() (to be flexible with respect to future flags notify_query_entry_{created,removed}() should be extended, too). Depending on whether the flag is set, the function either sends the moved or the removed+created events. CU, Ingo