(fixed up mailing list addresses) On Tue, Mar 13, 2012 at 03:05:51PM -0700, Tejun Heo wrote: > Hey, Matt. > > On Tue, Mar 13, 2012 at 02:45:26PM -0700, Matt Helsley wrote: > > If you want to spend your time doing archaeology there are some old threads > > that touch on this idea (roughly around 2003-2005). One point against the > > idea that I distinctly recall: > > > > Somewhat like configfs, object lifetimes in cgroups are determined > > primarily by the user whereas sysfs object lifetimes are primarily > > determined by the kernel. I think the closest we come to user-determined > > objects in sysfs occur through debugfs, and module loading/unloading. > > However those involve mount/umount and modprobe/rmmod rather than > > mkdir/rmdir to create and remove the objects. > > The thing is that sysfs itself has been almost completely rewritten > since that time to 1. decouple internal representation from vfs > objects and 2. provide proper isolation between the userland and > kernel code exposing data through sysfs. > > #1 began mostly due to the large size of dentries and inodes but, with > the benefit of hindsight, I think it just was a bad idea to piggyback > on vfs objects for object life-cycle management and locking for stuff > which is wholely described in memory with simplistic locking. > > #2 was necessary to avoid hanging device detach due to open sysfs file > from userland. sysfs now has notion of "active access" encompassing > only each show/store op invocation and it only guarantees that the > associated device doesn't go away while active accesses are in > progress. > > The sysfs heritage is almost recognizable and unfortunately almost the > same set of problems (nobody wants show/store ops to be called on > unlinked css waiting for references to be drained). As refactoring > and sharing sysfs won't be a trivial task, my plan is to first augment > cgroupfs as necessary with longer term goal of converging and later > sharing the same code with sysfs. Sorry, forgot to reply to the userland-determined object creation/deletion part. I don't think there are direct creation cases in sysfs but there are plenty of deletion going on, especially the kind where a file requests to delete its parent directly (*/device/delete). While using mkdir/rmdir indeed is different for cgroupfs, I don't think that would make too much of difference. Both calls are essentially unused by sysfs currently and there's nothing preventing addition of callbacks there. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>