All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Rolland" <rol@as2917.net>
To: "'John McCutchan'" <ttb@tentacle.dhs.org>,
	<rudi@lambda-computing.de>, <linux-kernel@vger.kernel.org>,
	<jamie@shareable.org>, <tridge@samba.org>,
	<viro@parcelfarce.linux.theplanet.co.uk>, <torvalds@osdl.org>,
	<alexl@redhat.com>, <rml@ximian.com>
Subject: Re: [RFC,PATCH] dnotify: enhance or replace?
Date: Wed, 24 Mar 2004 21:00:01 +0100	[thread overview]
Message-ID: <200403242000.i2OK0AA01266@tag.witbe.net> (raw)
In-Reply-To: <1080158032.30769.13.camel@vertex>


Hello,

> could be done. Inode numbers are not unique, but is there any 
> way to get
> a unique identifier on a file without using an open file? I have come
I wonder if adding to the inode number something like the device
id is not enough to create some "unique key"...

> up with a few ideas.. I don't think they are very good, but here is
> goes,
> 
> - When user passes fd to kernel to watch, the kernel takes over this
>   fd, making it invalid in user space ( I know this is a 
> terrible hack)
>   then when a volume is unmounted, the kernel can walk the list of 
>   open fd's using for notifacation and close them, before 
> attempting to
>   unmount.
No, this is bad, because it would require to use dedicated fd for
dnotify. If I open a file/directory, give it to dnotify, I don't
want to re-open it to use it, read it, or anything else...
 
> - The user passes a path to the kernel, the kernel does some work so
>   that it can track anything to do with that path, and again when
>   an unmount is called the kernel cleans up anything used for
>   notification. 
That sounds much better to me...

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur

"Some people dream of success... while others wake up and work hard at it" 



  reply	other threads:[~2004-03-24 20:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-24 14:17 [RFC,PATCH] dnotify: enhance or replace? Rüdiger Klaehn
2004-03-24 15:40 ` Alexander Larsson
2004-03-24 16:15   ` Rüdiger Klaehn
     [not found]     ` <1080202140.8108.101.camel@localhost.localdomain>
2004-03-26  9:52       ` Rüdiger Klaehn
     [not found]       ` <4062C63F.6050907@gamemakers.de>
     [not found]         ` <1080219862.8108.138.camel@localhost.localdomain>
2004-03-26  9:59           ` Rüdiger Klaehn
2004-03-24 16:37   ` John McCutchan
2004-03-24 16:54     ` Rüdiger Klaehn
2004-03-24 19:53       ` John McCutchan
2004-03-24 20:00         ` Paul Rolland [this message]
2004-03-24 20:04         ` viro
2004-03-26 10:12           ` Rüdiger Klaehn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200403242000.i2OK0AA01266@tag.witbe.net \
    --to=rol@as2917.net \
    --cc=alexl@redhat.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@ximian.com \
    --cc=rudi@lambda-computing.de \
    --cc=torvalds@osdl.org \
    --cc=tridge@samba.org \
    --cc=ttb@tentacle.dhs.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.