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: Serge E. Hallyn on 31 Mar 2010 13:30 Quoting Eric W. Biederman (ebiederm(a)xmission.com): > > 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. > > I have been running these patches in some form for well over a > year so the basics should at least be solid. > > This patchset is currently against 2.6.34-rc1. > > This patchset is just the basic infrastructure a couple of more pretty > trivial patches are needed to actually enable network namespaces to use this. > My current plan is to send those after these patches have made it through > review. Thanks very much for keeping this going, Eric! I'm going to keep looking through the code some more, but so far I see no problems. Acked-by: Serge Hallyn <serue(a)us.ibm.com> to the full patchset. I'm really hoping you'll also include the patch to implement the netns support (i.e. basically commit fdc0adeaa8bfab9a179e1eb349cab400ddb70403 that you sent inline this morning to Tejun). thanks, -serge -- 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 14:20 "Serge E. Hallyn" <serue(a)us.ibm.com> writes: > Quoting Eric W. Biederman (ebiederm(a)xmission.com): >> >> 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. >> >> I have been running these patches in some form for well over a >> year so the basics should at least be solid. >> >> This patchset is currently against 2.6.34-rc1. >> >> This patchset is just the basic infrastructure a couple of more pretty >> trivial patches are needed to actually enable network namespaces to use this. >> My current plan is to send those after these patches have made it through >> review. > > Thanks very much for keeping this going, Eric! I'm going to keep > looking through the code some more, but so far I see no problems. > > Acked-by: Serge Hallyn <serue(a)us.ibm.com> > > to the full patchset. I'm really hoping you'll also include the > patch to implement the netns support (i.e. basically commit > fdc0adeaa8bfab9a179e1eb349cab400ddb70403 that you sent inline this > morning to Tejun). One step at a time. My goal is to have it all send out and reviewed in time for 2.6.35. 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: Ben Hutchings on 2 Apr 2010 21:00 On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote: > 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). [...] block vs class/block is arguable, but as for abstracting the difference between bus and class... why? Each bus defines a device interface covering enumeration, identification, power management and various aspects of their connection to the host. This interface is implemented by the bus driver. Each class defines a device interface covering functionality provided to user-space or higher level kernel components (block interface to filesystems, net driver interface to the networking core, etc). This interface is implemented by multiple device-specific drivers. So while buses and classes both define device interfaces, they are fundamentally different types of interface. And there are 'subsystems' that don't have devices at all (time, RCU, perf, ...). If you're going to expose the set of subsystems, don't they belong in there? But then, what would you put in their directories? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
From: Kay Sievers on 3 Apr 2010 04:40 On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben(a)decadent.org.uk> wrote: > On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote: >> Yeah, /sys/bus/, which is the only sane layout of the needlessly >> different 3 versions of the same thing (bus, class, block). > [...] > > block vs class/block is arguable, That's already done long ago. > but as for abstracting the difference > between bus and class... why? There is absolutely no need to needlessly export two versions of the same thing. These directories serve no other purpose than to collect all devices of the same subsystem. There is no useful information that belongs to the type class or bus, they are both the same. Like "inputX" is implemented as a class, but is much more like a bus. And "usb" are devices, which are more a class of devices, and the interfaces and contollers belong to a bus. There is really no point to make userspace needlessly complicated to distinguish the both. We also have already a buch of subsystems which moved from class to bus because they needed to express hierarchy between the same devices. So the goal is to have only one type of subsystem to solve these problems. > Each bus defines a device interface covering enumeration, > identification, power management and various aspects of their connection > to the host. This interface is implemented by the bus driver. Sure, but that does not mean that class is a useful layout, or that class devices can not do the same. > Each class defines a device interface covering functionality provided to > user-space or higher level kernel components (block interface to > filesystems, net driver interface to the networking core, etc). This > interface is implemented by multiple device-specific drivers. That's absolutely wrong. Classes are just too simple uses of the same thing. We have many class devices which are not "interfaces", and we have bus devices which are interfaces. > So while buses and classes both define device interfaces, they are > fundamentally different types of interface. No, they are not. They are just "devices". There is no useful difference these two different types expose. And the class layout is fundamentally broken, and not extendable. Peole mix lists of devices with custom subsystem-wide attributes, which we need to stop from doing this. The bus layout can carry custom directories, which is why we want that by default for all "classifications". > And there are 'subsystems' > that don't have devices at all (time, RCU, perf, ...). If you're going > to expose the set of subsystems, don't they belong in there? > But then, We are talking about the current users in /sys, and the difference in the sysfs export between /sys/bus and /sys/class. > what would you put in their directories? We are not talking about anything not in /sys currently. 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: Ben Hutchings on 3 Apr 2010 12:10
On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote: > On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben(a)decadent.org.uk> wrote: > > On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote: > >> Yeah, /sys/bus/, which is the only sane layout of the needlessly > >> different 3 versions of the same thing (bus, class, block). > > [...] > > > > block vs class/block is arguable, > > That's already done long ago. > > > but as for abstracting the difference > > between bus and class... why? > > There is absolutely no need to needlessly export two versions of the > same thing. These directories serve no other purpose than to collect > all devices of the same subsystem. There is no useful information that > belongs to the type class or bus, they are both the same. Like > "inputX" is implemented as a class, but is much more like a bus. Really, how do you enumerate 'input' buses? > And "usb" are devices, which are more a class of devices, and the > interfaces and contollers belong to a bus. What common higher-level functionality do USB devices provide? > There is really no point to make userspace needlessly complicated to > distinguish the both. > > We also have already a buch of subsystems which moved from class to > bus because they needed to express hierarchy between the same devices. > So the goal is to have only one type of subsystem to solve these > problems. That's interesting. Which were those? [...] > > So while buses and classes both define device interfaces, they are > > fundamentally different types of interface. > > No, they are not. They are just "devices". There is no useful > difference these two different types expose. And the class layout is > fundamentally broken, and not extendable. Peole mix lists of devices > with custom subsystem-wide attributes, which we need to stop from > doing this. The bus layout can carry custom directories, which is why > we want that by default for all "classifications". [...] I understand that you want to clean up a mess, but how do you know you're not going to break user-space that depends on some of this mess? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. |