tagged sysfs support
in [Kernel]
|
Prev: x86,kgdb: Always initialize the hw breakpoint attribute
Next: [PATCH 1/1] x86,kgdb: Always initialize the hw breakpoint attribute
From: Kay Sievers on 30 Mar 2010 15:00 On Tue, Mar 30, 2010 at 20:30, Eric W. Biederman <ebiederm(a)xmission.com> wrote: > > The main short coming of using multiple network namespaces today > is that only network devices for the primary network namespaces > can be put in the kobject layer and sysfs. > > This is essentially the earlier version of this patchset that was > reviewed before, just now on top of a version of sysfs that doesn't > need cleanup patches to support it. Just to check if we are not in conflict with planned changes, and how to possibly handle them: There is the plan and ongoing work to unify classes and buses, export them at /sys/subsystem in the same layout of the current /sys/bus/. The decision to export buses and classes as two different things (which they aren't) is the last major piece in the sysfs layout which needs to be fixed. It would mean that /sys/subsystem/net/devices/* would look like /sys/class/net/* today. But at the /sys/subsystem/net/ directory could be global network-subsystem-wide control files which would need to be namespaced too. (The network subsystem does not use subsytem-global files today, but a bunch of other classes do.) This could be modeled into the current way of doing sysfs namespaces? A /sys/bus/<subsystem>/ directory hierarchy would need to be namespaced, not just a single plain directory with symlinks. Would that work? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 30 Mar 2010 19:10 Kay Sievers <kay.sievers(a)vrfy.org> writes: > On Tue, Mar 30, 2010 at 20:30, Eric W. Biederman <ebiederm(a)xmission.com> wrote: >> >> The main short coming of using multiple network namespaces today >> is that only network devices for the primary network namespaces >> can be put in the kobject layer and sysfs. >> >> This is essentially the earlier version of this patchset that was >> reviewed before, just now on top of a version of sysfs that doesn't >> need cleanup patches to support it. > > Just to check if we are not in conflict with planned changes, and how > to possibly handle them: > > There is the plan and ongoing work to unify classes and buses, export > them at /sys/subsystem in the same layout of the current /sys/bus/. > The decision to export buses and classes as two different things > (which they aren't) is the last major piece in the sysfs layout which > needs to be fixed. Interesting. We will symlinks ie: /sys/class -> /sys/subsystem /sys/bus -> /sys/subsystem to keep from breaking userspace. > It would mean that /sys/subsystem/net/devices/* would look like > /sys/class/net/* today. But at the /sys/subsystem/net/ directory could > be global network-subsystem-wide control files which would need to be > namespaced too. (The network subsystem does not use subsytem-global > files today, but a bunch of other classes do.) > > This could be modeled into the current way of doing sysfs namespaces? > A /sys/bus/<subsystem>/ directory hierarchy would need to be > namespaced, not just a single plain directory with symlinks. Would > that work? I'm not entirely clear on what you are doing but it all sounds like it will fit within what I am doing. Right now I have /sys/class/net, /sys/devices/virtual/net and a bunch of other net directories becoming tagged and only showing up in the appropriately mounted sysfs. We track them all in the class kset and as long as we extend that capability when the subsystem change happens in sysfs all should be well. Today we have /sys/class/net/bonding_master. For now I have that as an untagged but the implementation is aware of which network namespace your current process is in. Thinking about that a little more it would be better to make that file tagged so that userspace can see different versions for the different network namespaces. Joy. I expect other control files will be the same. In general it doesn't make sense to add control files for networking. as they easily conflict with legal network device names and thus create the possibility of breaking someones userspace. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 31 Mar 2010 02:00 On Wed, Mar 31, 2010 at 01:04, Eric W. Biederman <ebiederm(a)xmission.com> wrote: > Kay Sievers <kay.sievers(a)vrfy.org> writes: >> On Tue, Mar 30, 2010 at 20:30, Eric W. Biederman <ebiederm(a)xmission.com> wrote: >>> >>> The main short coming of using multiple network namespaces today >>> is that only network devices for the primary network namespaces >>> can be put in the kobject layer and sysfs. >>> >>> This is essentially the earlier version of this patchset that was >>> reviewed before, just now on top of a version of sysfs that doesn't >>> need cleanup patches to support it. >> >> Just to check if we are not in conflict with planned changes, and how >> to possibly handle them: >> >> There is the plan and ongoing work to unify classes and buses, export >> them at /sys/subsystem in the same layout of the current /sys/bus/. >> The decision to export buses and classes as two different things >> (which they aren't) is the last major piece in the sysfs layout which >> needs to be fixed. > > Interesting. We will symlinks ie: > /sys/class -> /sys/subsystem > /sys/bus -> /sys/subsystem > to keep from breaking userspace. Yeah, /sys/bus/, which is the only sane layout of the needlessly different 3 versions of the same thing (bus, class, block). /sys/bus/<subsys> can just be a plain symlinks to the /sys/subsystem/<subsys> directories. /sys/class/<subsys> *could* be a symlink to the /sys/subsystem/<subsys>/devices/ directory, but we really don't want to continue to stupidly mix subsystem-wide control files with device lists anymore. The "devices" directory needs to be a strict list of devices, not some collection of random stuff, that it is today. :) So we either leave all the conceptually broken class attributes behind us, and put them at the /sys/subsystem/<subsys>/ level only, or we need to create the /sys/class/<subsys>/* stuff all as symlinks like we do today. I expect, we have to create /sys/class as we do today. Another problem to solve is that sysfs does not allow us to symlink regular files, only directories, so we can currently not create the class-wide attributes as symlinks to the proper file in /sys/subsystem/. >> It would mean that /sys/subsystem/net/devices/* would look like >> /sys/class/net/* today. But at the /sys/subsystem/net/ directory could >> be global network-subsystem-wide control files which would need to be >> namespaced too. (The network subsystem does not use subsytem-global >> files today, but a bunch of other classes do.) >> >> This could be modeled into the current way of doing sysfs namespaces? >> A /sys/bus/<subsystem>/ directory hierarchy would need to be >> namespaced, not just a single plain directory with symlinks. Would >> that work? > > I'm not entirely clear on what you are doing but it all sounds like it > will fit within what I am doing. The goal is to unify the 3 needlessly different versions of "device lists of the same subsystem". We have /sys/class, /sys/bus, /sys/block, and all of them will be unified at /sys/subsystem/ leaving the old names as compat links only. Unlike block and class, the /sys/subsystem/<subsys> directory can be extended with custom subdirectories and files, without mixing random files into device lists. With /sys/subsystem/, userspace can uniquely identify and find all devices at /sys/<subsys>/devices/<device-name>/ with only the subsystem and the device name. All devices in /sys/devices already have a symlink called "subsystem" which will point back to the corresponding /sys/subsystem/<subsys> directory, and the event environment already contains a variable SUBSYSTEM with the name. That would be the first time sysfs device interfaces have some idea of consistency. :) > Right now I have /sys/class/net, > /sys/devices/virtual/net and a bunch of other net directories becoming > tagged and only showing up in the appropriately mounted sysfs. We > track them all in the class kset and as long as we extend that capability > when the subsystem change happens in sysfs all should be well. Ok, sounds good. > Today we have /sys/class/net/bonding_master. For now I have that as > an untagged but the implementation is aware of which network namespace > your current process is in. Thinking about that a little more it > would be better to make that file tagged so that userspace can see > different versions for the different network namespaces. Joy. Yeah, that might make more sense in the end. > I expect other control files will be the same. Sounds like, yes. > In general it doesn't make sense to add control files for networking. > as they easily conflict with legal network device names and thus create > the possibility of breaking someones userspace. Yeah, it did not makes sense it the first place to mix devices lists with global attributes. It's a real mess what people do in sysfs. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 31 Mar 2010 02:30 On 03/31/2010 02:51 PM, Kay Sievers wrote: > Another problem to solve is that sysfs does not allow us to symlink > regular files, only directories, so we can currently not create the > class-wide attributes as symlinks to the proper file in > /sys/subsystem/. Making sysfs allow symlinks to attributes shouldn't be too hard if it's gonna help make things more logical overall. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 31 Mar 2010 03:00
Kay Sievers <kay.sievers(a)vrfy.org> writes: > On Wed, Mar 31, 2010 at 01:04, Eric W. Biederman <ebiederm(a)xmission.com> wrote: >> Kay Sievers <kay.sievers(a)vrfy.org> writes: > > Yeah, /sys/bus/, which is the only sane layout of the needlessly > different 3 versions of the same thing (bus, class, block). > > /sys/bus/<subsys> can just be a plain symlinks to the > /sys/subsystem/<subsys> directories. > > /sys/class/<subsys> *could* be a symlink to the > /sys/subsystem/<subsys>/devices/ directory, but we really don't want > to continue to stupidly mix subsystem-wide control files with device > lists anymore. The "devices" directory needs to be a strict list of > devices, not some collection of random stuff, that it is today. :) > > So we either leave all the conceptually broken class attributes behind > us, and put them at the /sys/subsystem/<subsys>/ level only, or we > need to create the /sys/class/<subsys>/* stuff all as symlinks like we > do today. I expect, we have to create /sys/class as we do today. Ideally we will keep new subsystem attributes from creeping into /sys/class/xxxx/ directories. > Another problem to solve is that sysfs does not allow us to symlink > regular files, only directories, so we can currently not create the > class-wide attributes as symlinks to the proper file in > /sys/subsystem/. That seems to be part of the everything is a kobject interface, and all kobjects are directories. I don't think supporting the symlinks will be particularly hard, although there are issues to consider with respect to making the symlinks come and go when the attributes do. >> >> I'm not entirely clear on what you are doing but it all sounds like it >> will fit within what I am doing. > > The goal is to unify the 3 needlessly different versions of "device > lists of the same subsystem". We have /sys/class, /sys/bus, > /sys/block, and all of them will be unified at /sys/subsystem/ leaving > the old names as compat links only. Unlike block and class, the > /sys/subsystem/<subsys> directory can be extended with custom > subdirectories and files, without mixing random files into device > lists. That makes sense. I took a quick look and /sys/block is already a compatibility define. So I don't expect any issues there. At a practical level there don't appear to be too many class attributes that will cause problems, but even a couple are enough to be a pain. > Yeah, it did not makes sense it the first place to mix devices lists > with global attributes. It's a real mess what people do in sysfs. I was very disappointed in sysfs the first time I saw someone add writable attributes. But sysfs is here now. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |