Re: [PATCH 0/4] FS: userspace notification of errors

[Denis Karpov]

On Fri, Jun 05, 2009 at 01:07:59PM +0200, Bityutskiy Artem (Nokia-D/Helsinki) wrote:
> 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? 

This is doable, e.g. in the form of optional fields "tag[:value]"
(field 7, Documentation/filesystems/proc.txti for mountinfo).

Kay, sorry I didn't answer to your email separately. I tried to summarize
and address all the posted comments/critiques in a single email earlier 
in this thread.
http://marc.info/?l=linux-kernel&m=124412575828015&w=2

But is using procfs generally a good idea ? Last several years all a lot of
stuff moved out from procfs into sysfs. Not to forget what procfs is
originally meant for: storing the proceses related information.

/proc/self/mountinfo solution:
pros:
- existing solution
cons:
- polling only
- dedicated userspace tool to poll/parse/act
- additional parsing overhead and event filtering (mountinfo changes for many
  reasons)
- probably this info does not belong to procfs

/sys/fs/<fs>/<volume>/{attributes,..} solution:
pros:
- nice hierarchy reflecting structure of entities in the kernel
- extensible (other errors, conditions, events can be reflected) 
- no parsing: dedicated file for each attribute
- uevent interface with existing userspace tool (udev); 
  (polling is still possible)
- /sys/fs seems to be a perfect fit for the purpose judging by ext4 example
cons:
- uevent interface is unneeded extra(?); can be made optional, per attribute
- ...

Denis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/