public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John McCutchan <ttb@tentacle.dhs.org>
To: 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 14:53:52 -0500	[thread overview]
Message-ID: <1080158032.30769.13.camel@vertex> (raw)
In-Reply-To: <4061BD2E.2060900@gamemakers.de>

One of the big requirements for a dnotify replacement is this

* Some way to not have an open file descriptor for each directory you
are monitoring. This causes so many problems when unmounting, and this
is really the most noticable problem for the user.

I wanted to get some possible ideas from kernel hackers about how this
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
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.

- 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. 

Both of these ideas are similar, does anyone have a better idea?

John

  reply	other threads:[~2004-03-24 19:47 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 [this message]
2004-03-24 20:00         ` Paul Rolland
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=1080158032.30769.13.camel@vertex \
    --to=ttb@tentacle.dhs.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox