On Thu, Aug 24, 2017 at 08:04:41PM +0200, Luis R. Rodriguez wrote: > While all this is nice, I'm sure we're all aware of the dangers of setting > things in stone through sysfs, its likely already decided for the above > tunables, but adding a uevent *is* yet another layer of user interface > which userspace can *expect* and we should be certain we want this so > we won't regress userspace later. > > Just saying, we better damn be sure this is the way we want to go. I'm not sure what you are trying to warn us about? :/ These are events on an XFS specific kobj, it's not a generic VFS filesystem event we are generating here. It's no different from a hardware device generating it's own uevents to tell userspace something changed in the device. A quick grep would have told you that GFS2 already has it's own online/offline uevents (e.g. gfs2_online_uevent()), as does the DLM code. Orangefs seems to use quite a few of uevent notifications, too. So it's not like we're doing something controversial or unique here, nor something that locks us out of a non-existent VFS event notification mechanism. Please, talk all you want about a Grand Unified VFS Event Notification infrastructure and filesystem tool libraries, but please don't hijack an unrelated discussion to do it. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
