All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Denis Karpov <ext-denis.2.karpov@nokia.com>,
	axboe@kernel.dk, hirofumi@mail.parknet.co.jp,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, adrian.hunter@nokia.com
Subject: Re: [PATCH 0/4] FS: userspace notification of errors
Date: Fri, 05 Jun 2009 14:07:59 +0300	[thread overview]
Message-ID: <4A28FC8F.5020802@nokia.com> (raw)
In-Reply-To: <ac3eb2510906040553j294f1015wfb7deb4b4fc63afc@mail.gmail.com>

Kay Sievers wrote:
> And I don't think we want several event sources for the same thing,
> uevents _and_ pollable sysfs files.
> 
> We already raise events on /proc/self/mountinfo when the mount tree
> changes, I guess that's where fs specific stuff belongs, and it will
> work with all kind of filesystem setups, regardless of the devices
> below it. This is also the established interface for flags and options
> and the current state of the filesystem, and does not mix filesystem
> options into block device interfaces.
> 
> /proc/self/mountinfo could also work properly with namespaces which
> might have different meaning for a device in a different namespace.

Well, Denis suggests /sys/fs instead. But how would we pass stuff like
error code via /proc/self/mountinfo? And what if later some one wants
to provide user-space stuff like bogus inode number? IMO, /sys/fs
sounds better.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Denis Karpov <ext-denis.2.karpov@nokia.com>,
	axboe@kernel.dk, hirofumi@mail.parknet.co.jp,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, adrian.hunter@nokia.com
Subject: Re: [PATCH 0/4] FS: userspace notification of errors
Date: Fri, 05 Jun 2009 14:07:59 +0300	[thread overview]
Message-ID: <4A28FC8F.5020802@nokia.com> (raw)
In-Reply-To: <ac3eb2510906040553j294f1015wfb7deb4b4fc63afc@mail.gmail.com>

Kay Sievers wrote:
> And I don't think we want several event sources for the same thing,
> uevents _and_ pollable sysfs files.
> 
> We already raise events on /proc/self/mountinfo when the mount tree
> changes, I guess that's where fs specific stuff belongs, and it will
> work with all kind of filesystem setups, regardless of the devices
> below it. This is also the established interface for flags and options
> and the current state of the filesystem, and does not mix filesystem
> options into block device interfaces.
> 
> /proc/self/mountinfo could also work properly with namespaces which
> might have different meaning for a device in a different namespace.

Well, Denis suggests /sys/fs instead. But how would we pass stuff like
error code via /proc/self/mountinfo? And what if later some one wants
to provide user-space stuff like bogus inode number? IMO, /sys/fs
sounds better.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  parent reply	other threads:[~2009-06-05 11:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-03 15:05 [PATCH 0/4] FS: userspace notification of errors Denis Karpov
2009-06-03 15:05 ` [PATCH 1/4] FS: filesystem corruption notification Denis Karpov
2009-06-03 15:05   ` [PATCH 2/4] FAT: generalize errors and warning printing Denis Karpov
2009-06-03 15:05   ` [PATCH 3/4] FAT: add 'notify' mount option Denis Karpov
2009-06-03 18:59     ` Andrew Morton
2009-06-03 15:05   ` [PATCH 4/4] EXT2: " Denis Karpov
2009-06-03 19:00     ` Andrew Morton
2009-06-10 21:03     ` Pavel Machek
2009-06-03 18:58   ` [PATCH 1/4] FS: filesystem corruption notification Andrew Morton
2009-06-03 15:36 ` [PATCH 0/4] FS: userspace notification of errors Eric Sandeen
2009-06-03 18:56 ` Andrew Morton
2009-06-04  1:59   ` Jamie Lokier
2009-06-04  5:57   ` Artem Bityutskiy
2009-06-04  5:57     ` Artem Bityutskiy
2009-06-04 14:27     ` Denis Karpov
2009-06-10 21:03       ` Pavel Machek
2009-06-10 21:03         ` Pavel Machek
2009-06-10 21:05     ` Pavel Machek
2009-06-04 12:53   ` Kay Sievers
2009-06-04 12:53     ` Kay Sievers
2009-06-04 14:29     ` Russell Cattelan
2009-06-05  7:25     ` Jon Masters
2009-06-05 11:07     ` Artem Bityutskiy [this message]
2009-06-05 11:07       ` Artem Bityutskiy
2009-06-05 11:51       ` Denis Karpov
2009-06-05 13:06         ` Kay Sievers
2009-06-05 13:06         ` Kay Sievers
2009-06-05 13:06           ` Kay Sievers
2009-06-09 13:49           ` Jan Kara
2009-06-03 22:30 ` Jan Kara
2009-06-04  6:10   ` Artem Bityutskiy
2009-06-04  6:10     ` Artem Bityutskiy

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=4A28FC8F.5020802@nokia.com \
    --to=artem.bityutskiy@nokia.com \
    --cc=adrian.hunter@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=ext-denis.2.karpov@nokia.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.