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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
