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
next prev parent 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