On Wed, Jun 3, 2009 at 20:56, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 3 Jun 2009 18:05:14 +0300 Denis Karpov <ext-denis.2.karpov@xxxxxxxxx> wrote: > hm, I'm uncertain on the desirability or otherwise of the overall feature. > > Are there users or distros or device manufacturers asking for this? > Where did the requirement come from? I think we really need something like this to propagate such errors to userpace. Printing something to the kernel log is not an useful interface in any way. But I don't think we want it that way, not with uevents, not with sysfs, and not tied to block devices. Uevents should not be used for error reporting, unless it is well defined within the _device_ context, which a filesystem on top of a blockdev isn't. We could argue to get events for bad blocks of a device, but I don't think we want filesystem related stuff ever in device uevents. For the same reason, there should be no unconditional fs-specific sysfs file below a block device. Block device interfaces for filesystems can not handle device-less virtual mounts which are common these days. There is no direct relation from the device to the filesystem - so this would only work for simple direct mounts, which isn't sufficient for a higher-level interface like this. 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. Thanks, Kay -- 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
