Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 11:34:00AM -0700, Tejun Heo wrote: > On Sun, Mar 10, 2013 at 06:50:34PM +0100, Kay Sievers wrote: > > > Yes, but I can keep Tejun's patch in my local queue for now, dbus is > > > going to not make 3.10, right? > > > > No, sure not. It's just something we will need there too, but there is > > no hurry, it's only a cosmetic issue anyway and nothing that matters > > functionality-wise. > > In that case, I'll just route it together with the rest of workqueue > changes with Greg's ack added. The patch is applied to wq/for-3.10-subsys_virtual_register which contains only this patch on top of v3.9-rc1. If somebody ever needs it in this cycle, please feel free to pull the following branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.10-subsys_virtual_register Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 11:34:00AM -0700, Tejun Heo wrote: On Sun, Mar 10, 2013 at 06:50:34PM +0100, Kay Sievers wrote: Yes, but I can keep Tejun's patch in my local queue for now, dbus is going to not make 3.10, right? No, sure not. It's just something we will need there too, but there is no hurry, it's only a cosmetic issue anyway and nothing that matters functionality-wise. In that case, I'll just route it together with the rest of workqueue changes with Greg's ack added. The patch is applied to wq/for-3.10-subsys_virtual_register which contains only this patch on top of v3.9-rc1. If somebody ever needs it in this cycle, please feel free to pull the following branch. git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.10-subsys_virtual_register Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 06:50:34PM +0100, Kay Sievers wrote: > > Yes, but I can keep Tejun's patch in my local queue for now, dbus is > > going to not make 3.10, right? > > No, sure not. It's just something we will need there too, but there is > no hurry, it's only a cosmetic issue anyway and nothing that matters > functionality-wise. In that case, I'll just route it together with the rest of workqueue changes with Greg's ack added. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 6:24 PM, Greg Kroah-Hartman wrote: > On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote: >> On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman >> wrote: >> > On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: >> >> Hey, guys. >> >> >> >> On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: >> >> > > Sorry for the delay, I'm at a conference all this week, and haven't >> >> > > had >> >> > > much time to think about this. >> >> > > >> >> > > If Kay says this is ok for now, that's good enough for me. >> >> > >> >> > Yes, it looks fine to me. If we provide the unified handling of >> >> > classes and buses some day, this can probably go away, but until that >> >> > it looks fine and is straight forward to do it that way, >> >> >> >> How should this be routed? I can take it but Kay needs it too so >> >> workqueue tree probably isn't the best fit although I can set up a >> >> separate branch if needed. >> > >> > What patch set does Kay need it for? I have no objection for you to >> > take it through the workqueue tree: >> >> The dbus bus has the same issues and needs the devices put under >> virtual/ and not the devices/ root. > > Yes, but I can keep Tejun's patch in my local queue for now, dbus is > going to not make 3.10, right? No, sure not. It's just something we will need there too, but there is no hurry, it's only a cosmetic issue anyway and nothing that matters functionality-wise. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote: > On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman > wrote: > > On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: > >> Hey, guys. > >> > >> On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: > >> > > Sorry for the delay, I'm at a conference all this week, and haven't had > >> > > much time to think about this. > >> > > > >> > > If Kay says this is ok for now, that's good enough for me. > >> > > >> > Yes, it looks fine to me. If we provide the unified handling of > >> > classes and buses some day, this can probably go away, but until that > >> > it looks fine and is straight forward to do it that way, > >> > >> How should this be routed? I can take it but Kay needs it too so > >> workqueue tree probably isn't the best fit although I can set up a > >> separate branch if needed. > > > > What patch set does Kay need it for? I have no objection for you to > > take it through the workqueue tree: > > The dbus bus has the same issues and needs the devices put under > virtual/ and not the devices/ root. Yes, but I can keep Tejun's patch in my local queue for now, dbus is going to not make 3.10, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman wrote: > On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: >> Hey, guys. >> >> On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: >> > > Sorry for the delay, I'm at a conference all this week, and haven't had >> > > much time to think about this. >> > > >> > > If Kay says this is ok for now, that's good enough for me. >> > >> > Yes, it looks fine to me. If we provide the unified handling of >> > classes and buses some day, this can probably go away, but until that >> > it looks fine and is straight forward to do it that way, >> >> How should this be routed? I can take it but Kay needs it too so >> workqueue tree probably isn't the best fit although I can set up a >> separate branch if needed. > > What patch set does Kay need it for? I have no objection for you to > take it through the workqueue tree: The dbus bus has the same issues and needs the devices put under virtual/ and not the devices/ root. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: > Hey, guys. > > On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: > > > Sorry for the delay, I'm at a conference all this week, and haven't had > > > much time to think about this. > > > > > > If Kay says this is ok for now, that's good enough for me. > > > > Yes, it looks fine to me. If we provide the unified handling of > > classes and buses some day, this can probably go away, but until that > > it looks fine and is straight forward to do it that way, > > How should this be routed? I can take it but Kay needs it too so > workqueue tree probably isn't the best fit although I can set up a > separate branch if needed. What patch set does Kay need it for? I have no objection for you to take it through the workqueue tree: Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: > > Sorry for the delay, I'm at a conference all this week, and haven't had > > much time to think about this. > > > > If Kay says this is ok for now, that's good enough for me. > > Yes, it looks fine to me. If we provide the unified handling of > classes and buses some day, this can probably go away, but until that > it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. What patch set does Kay need it for? I have no objection for you to take it through the workqueue tree: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. What patch set does Kay need it for? I have no objection for you to take it through the workqueue tree: The dbus bus has the same issues and needs the devices put under virtual/ and not the devices/ root. Kay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote: On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. What patch set does Kay need it for? I have no objection for you to take it through the workqueue tree: The dbus bus has the same issues and needs the devices put under virtual/ and not the devices/ root. Yes, but I can keep Tejun's patch in my local queue for now, dbus is going to not make 3.10, right? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 6:24 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote: On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote: Hey, guys. On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote: Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, How should this be routed? I can take it but Kay needs it too so workqueue tree probably isn't the best fit although I can set up a separate branch if needed. What patch set does Kay need it for? I have no objection for you to take it through the workqueue tree: The dbus bus has the same issues and needs the devices put under virtual/ and not the devices/ root. Yes, but I can keep Tejun's patch in my local queue for now, dbus is going to not make 3.10, right? No, sure not. It's just something we will need there too, but there is no hurry, it's only a cosmetic issue anyway and nothing that matters functionality-wise. Kay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 10, 2013 at 06:50:34PM +0100, Kay Sievers wrote: Yes, but I can keep Tejun's patch in my local queue for now, dbus is going to not make 3.10, right? No, sure not. It's just something we will need there too, but there is no hurry, it's only a cosmetic issue anyway and nothing that matters functionality-wise. In that case, I'll just route it together with the rest of workqueue changes with Greg's ack added. Thanks! -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Fri, Mar 8, 2013 at 12:31 AM, Greg Kroah-Hartman wrote: > On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote: >> On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: >> > On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman >> > wrote: >> > > On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: >> > >> Kay tells me the most appropriate place to expose workqueues to >> > >> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is >> > >> symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking >> > >> a way to do that outside of driver core as virtual_device_parent() >> > >> isn't exported and there's no inteface to conveniently create a >> > >> virtual subsystem. >> > > >> > > I'm almost afraid to ask what you want to export to userspace for a >> > > workqueue that userspace would care about... >> > > >> > > If you create a subsystem, the devices will show up under the virtual >> > > "bus" if you don't give them a parent, so this patch shouldn't be >> > > needed, unless you are abusing the driver model. What am I missing >> > > here? >> > >> > Unfortunately, the parent == NULL --> /sys/devices/virtual// >> > we have only implemented for classes, and not for buses. We should fix >> > that. >> >> Greg, how should I proceed on this? As I wrote before, I don't really >> care about where or how. As long as I can make workqueues visible to >> userland, I'm happy. > > Sorry for the delay, I'm at a conference all this week, and haven't had > much time to think about this. > > If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote: > On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: > > On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman > > wrote: > > > On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: > > >> Kay tells me the most appropriate place to expose workqueues to > > >> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is > > >> symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking > > >> a way to do that outside of driver core as virtual_device_parent() > > >> isn't exported and there's no inteface to conveniently create a > > >> virtual subsystem. > > > > > > I'm almost afraid to ask what you want to export to userspace for a > > > workqueue that userspace would care about... > > > > > > If you create a subsystem, the devices will show up under the virtual > > > "bus" if you don't give them a parent, so this patch shouldn't be > > > needed, unless you are abusing the driver model. What am I missing > > > here? > > > > Unfortunately, the parent == NULL --> /sys/devices/virtual// > > we have only implemented for classes, and not for buses. We should fix > > that. > > Greg, how should I proceed on this? As I wrote before, I don't really > care about where or how. As long as I can make workqueues visible to > userland, I'm happy. Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote: On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: Kay tells me the most appropriate place to expose workqueues to userland would be /sys/devices/virtual/workqueues/WQ_NAME which is symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking a way to do that outside of driver core as virtual_device_parent() isn't exported and there's no inteface to conveniently create a virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? Unfortunately, the parent == NULL -- /sys/devices/virtual/subsys/ we have only implemented for classes, and not for buses. We should fix that. Greg, how should I proceed on this? As I wrote before, I don't really care about where or how. As long as I can make workqueues visible to userland, I'm happy. Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Fri, Mar 8, 2013 at 12:31 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote: On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: Kay tells me the most appropriate place to expose workqueues to userland would be /sys/devices/virtual/workqueues/WQ_NAME which is symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking a way to do that outside of driver core as virtual_device_parent() isn't exported and there's no inteface to conveniently create a virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? Unfortunately, the parent == NULL -- /sys/devices/virtual/subsys/ we have only implemented for classes, and not for buses. We should fix that. Greg, how should I proceed on this? As I wrote before, I don't really care about where or how. As long as I can make workqueues visible to userland, I'm happy. Sorry for the delay, I'm at a conference all this week, and haven't had much time to think about this. If Kay says this is ok for now, that's good enough for me. Yes, it looks fine to me. If we provide the unified handling of classes and buses some day, this can probably go away, but until that it looks fine and is straight forward to do it that way, Thanks, Kay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: > On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman > wrote: > > On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: > >> Kay tells me the most appropriate place to expose workqueues to > >> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is > >> symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking > >> a way to do that outside of driver core as virtual_device_parent() > >> isn't exported and there's no inteface to conveniently create a > >> virtual subsystem. > > > > I'm almost afraid to ask what you want to export to userspace for a > > workqueue that userspace would care about... > > > > If you create a subsystem, the devices will show up under the virtual > > "bus" if you don't give them a parent, so this patch shouldn't be > > needed, unless you are abusing the driver model. What am I missing > > here? > > Unfortunately, the parent == NULL --> /sys/devices/virtual// > we have only implemented for classes, and not for buses. We should fix > that. Greg, how should I proceed on this? As I wrote before, I don't really care about where or how. As long as I can make workqueues visible to userland, I'm happy. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote: On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: Kay tells me the most appropriate place to expose workqueues to userland would be /sys/devices/virtual/workqueues/WQ_NAME which is symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking a way to do that outside of driver core as virtual_device_parent() isn't exported and there's no inteface to conveniently create a virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? Unfortunately, the parent == NULL -- /sys/devices/virtual/subsys/ we have only implemented for classes, and not for buses. We should fix that. Greg, how should I proceed on this? As I wrote before, I don't really care about where or how. As long as I can make workqueues visible to userland, I'm happy. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman wrote: > On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: >> Kay tells me the most appropriate place to expose workqueues to >> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is >> symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking >> a way to do that outside of driver core as virtual_device_parent() >> isn't exported and there's no inteface to conveniently create a >> virtual subsystem. > > I'm almost afraid to ask what you want to export to userspace for a > workqueue that userspace would care about... > > If you create a subsystem, the devices will show up under the virtual > "bus" if you don't give them a parent, so this patch shouldn't be > needed, unless you are abusing the driver model. What am I missing > here? Unfortunately, the parent == NULL --> /sys/devices/virtual// we have only implemented for classes, and not for buses. We should fix that. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
Hello, Greg. On Sat, Mar 02, 2013 at 10:17:27AM -0800, Greg Kroah-Hartman wrote: > I'm almost afraid to ask what you want to export to userspace for a > workqueue that userspace would care about... Workqueue is being extended to support worker pools with custom attributes so that it can replace private worker pool implementations in writeback, btrfs and other places. They want to expose per-workqueue tunables to userland - nice level, cpu affinity and cgroup association of those IO threads to userland, so that's where the sysfs interface comes in. The export is opt-in and those workqueues should have well defined name. > If you create a subsystem, the devices will show up under the virtual > "bus" if you don't give them a parent, so this patch shouldn't be > needed, unless you are abusing the driver model. What am I missing > here? If you don't give the parent, it ends up in /sys/devices/ with symlinks appearing under /sys/bus/. I didn't know where to put it. Right under /sys/devices/ doesn't seem right to me. We already have one like that /sys/devices/software/ which actually is for perf software events and it just is weird. I was wondering where to put it and Kay told me that /sys/devices/virtual/ would be the best fit although we don't yet have proper interface for it, so the patch. I don't really care where it shows up and it apparently shouldn't matter for userland as long as /sys/bus/ part is there but /sys/virtual/ seems to be the best fit at the moment. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: > Kay tells me the most appropriate place to expose workqueues to > userland would be /sys/devices/virtual/workqueues/WQ_NAME which is > symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking > a way to do that outside of driver core as virtual_device_parent() > isn't exported and there's no inteface to conveniently create a > virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual "bus" if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: Kay tells me the most appropriate place to expose workqueues to userland would be /sys/devices/virtual/workqueues/WQ_NAME which is symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking a way to do that outside of driver core as virtual_device_parent() isn't exported and there's no inteface to conveniently create a virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
Hello, Greg. On Sat, Mar 02, 2013 at 10:17:27AM -0800, Greg Kroah-Hartman wrote: I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... Workqueue is being extended to support worker pools with custom attributes so that it can replace private worker pool implementations in writeback, btrfs and other places. They want to expose per-workqueue tunables to userland - nice level, cpu affinity and cgroup association of those IO threads to userland, so that's where the sysfs interface comes in. The export is opt-in and those workqueues should have well defined name. If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? If you don't give the parent, it ends up in /sys/devices/ with symlinks appearing under /sys/bus/. I didn't know where to put it. Right under /sys/devices/ doesn't seem right to me. We already have one like that /sys/devices/software/ which actually is for perf software events and it just is weird. I was wondering where to put it and Kay told me that /sys/devices/virtual/ would be the best fit although we don't yet have proper interface for it, so the patch. I don't really care where it shows up and it apparently shouldn't matter for userland as long as /sys/bus/ part is there but /sys/virtual/ seems to be the best fit at the moment. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()
On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote: Kay tells me the most appropriate place to expose workqueues to userland would be /sys/devices/virtual/workqueues/WQ_NAME which is symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking a way to do that outside of driver core as virtual_device_parent() isn't exported and there's no inteface to conveniently create a virtual subsystem. I'm almost afraid to ask what you want to export to userspace for a workqueue that userspace would care about... If you create a subsystem, the devices will show up under the virtual bus if you don't give them a parent, so this patch shouldn't be needed, unless you are abusing the driver model. What am I missing here? Unfortunately, the parent == NULL -- /sys/devices/virtual/subsys/ we have only implemented for classes, and not for buses. We should fix that. Kay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 30/31] driver/base: implement subsys_virtual_register()
Kay tells me the most appropriate place to expose workqueues to
userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking
a way to do that outside of driver core as virtual_device_parent()
isn't exported and there's no inteface to conveniently create a
virtual subsystem.
This patch implements subsys_virtual_register() by factoring out
subsys_register() from subsys_system_register() and using it with
virtual_device_parent() as the origin directory. It's identical to
subsys_system_register() other than the origin directory but we aren't
gonna restrict the device names which should be used under it.
This will be used to expose workqueue attributes to userland.
Signed-off-by: Tejun Heo
Cc: Kay Sievers
Cc: Greg Kroah-Hartman
---
Kay, does this look okay? If so, how should this be routed?
Thanks.
drivers/base/base.h| 2 ++
drivers/base/bus.c | 73 +++---
drivers/base/core.c| 2 +-
include/linux/device.h | 2 ++
4 files changed, 57 insertions(+), 22 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 6ee17bb..b8bdfe6 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -101,6 +101,8 @@ static inline int hypervisor_init(void) { return 0; }
extern int platform_bus_init(void);
extern void cpu_dev_init(void);
+struct kobject *virtual_device_parent(struct device *dev);
+
extern int bus_add_device(struct device *dev);
extern void bus_probe_device(struct device *dev);
extern void bus_remove_device(struct device *dev);
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 24eb078..d229858 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -1205,26 +1205,10 @@ static void system_root_device_release(struct device
*dev)
{
kfree(dev);
}
-/**
- * subsys_system_register - register a subsystem at /sys/devices/system/
- * @subsys: system subsystem
- * @groups: default attributes for the root device
- *
- * All 'system' subsystems have a /sys/devices/system/ root device
- * with the name of the subsystem. The root device can carry subsystem-
- * wide attributes. All registered devices are below this single root
- * device and are named after the subsystem with a simple enumeration
- * number appended. The registered devices are not explicitely named;
- * only 'id' in the device needs to be set.
- *
- * Do not use this interface for anything new, it exists for compatibility
- * with bad ideas only. New subsystems should use plain subsystems; and
- * add the subsystem-wide attributes should be added to the subsystem
- * directory itself and not some create fake root-device placed in
- * /sys/devices/system/.
- */
-int subsys_system_register(struct bus_type *subsys,
- const struct attribute_group **groups)
+
+static int subsys_register(struct bus_type *subsys,
+ const struct attribute_group **groups,
+ struct kobject *parent_of_root)
{
struct device *dev;
int err;
@@ -1243,7 +1227,7 @@ int subsys_system_register(struct bus_type *subsys,
if (err < 0)
goto err_name;
- dev->kobj.parent = _kset->kobj;
+ dev->kobj.parent = parent_of_root;
dev->groups = groups;
dev->release = system_root_device_release;
@@ -1263,8 +1247,55 @@ err_dev:
bus_unregister(subsys);
return err;
}
+
+/**
+ * subsys_system_register - register a subsystem at /sys/devices/system/
+ * @subsys: system subsystem
+ * @groups: default attributes for the root device
+ *
+ * All 'system' subsystems have a /sys/devices/system/ root device
+ * with the name of the subsystem. The root device can carry subsystem-
+ * wide attributes. All registered devices are below this single root
+ * device and are named after the subsystem with a simple enumeration
+ * number appended. The registered devices are not explicitely named;
+ * only 'id' in the device needs to be set.
+ *
+ * Do not use this interface for anything new, it exists for compatibility
+ * with bad ideas only. New subsystems should use plain subsystems; and
+ * add the subsystem-wide attributes should be added to the subsystem
+ * directory itself and not some create fake root-device placed in
+ * /sys/devices/system/.
+ */
+int subsys_system_register(struct bus_type *subsys,
+ const struct attribute_group **groups)
+{
+ return subsys_register(subsys, groups, _kset->kobj);
+}
EXPORT_SYMBOL_GPL(subsys_system_register);
+/**
+ * subsys_virtual_register - register a subsystem at /sys/devices/virtual/
+ * @subsys: virtual subsystem
+ * @groups: default attributes for the root device
+ *
+ * All 'virtual' subsystems have a /sys/devices/system/ root device
+ * with the name of the subystem. The root device can carry subsystem-wide
+ * attributes. All registered devices are below this single root device.
+ * There's
[PATCH 30/31] driver/base: implement subsys_virtual_register()
Kay tells me the most appropriate place to expose workqueues to
userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking
a way to do that outside of driver core as virtual_device_parent()
isn't exported and there's no inteface to conveniently create a
virtual subsystem.
This patch implements subsys_virtual_register() by factoring out
subsys_register() from subsys_system_register() and using it with
virtual_device_parent() as the origin directory. It's identical to
subsys_system_register() other than the origin directory but we aren't
gonna restrict the device names which should be used under it.
This will be used to expose workqueue attributes to userland.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Kay Sievers kay.siev...@vrfy.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Kay, does this look okay? If so, how should this be routed?
Thanks.
drivers/base/base.h| 2 ++
drivers/base/bus.c | 73 +++---
drivers/base/core.c| 2 +-
include/linux/device.h | 2 ++
4 files changed, 57 insertions(+), 22 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 6ee17bb..b8bdfe6 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -101,6 +101,8 @@ static inline int hypervisor_init(void) { return 0; }
extern int platform_bus_init(void);
extern void cpu_dev_init(void);
+struct kobject *virtual_device_parent(struct device *dev);
+
extern int bus_add_device(struct device *dev);
extern void bus_probe_device(struct device *dev);
extern void bus_remove_device(struct device *dev);
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 24eb078..d229858 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -1205,26 +1205,10 @@ static void system_root_device_release(struct device
*dev)
{
kfree(dev);
}
-/**
- * subsys_system_register - register a subsystem at /sys/devices/system/
- * @subsys: system subsystem
- * @groups: default attributes for the root device
- *
- * All 'system' subsystems have a /sys/devices/system/name root device
- * with the name of the subsystem. The root device can carry subsystem-
- * wide attributes. All registered devices are below this single root
- * device and are named after the subsystem with a simple enumeration
- * number appended. The registered devices are not explicitely named;
- * only 'id' in the device needs to be set.
- *
- * Do not use this interface for anything new, it exists for compatibility
- * with bad ideas only. New subsystems should use plain subsystems; and
- * add the subsystem-wide attributes should be added to the subsystem
- * directory itself and not some create fake root-device placed in
- * /sys/devices/system/name.
- */
-int subsys_system_register(struct bus_type *subsys,
- const struct attribute_group **groups)
+
+static int subsys_register(struct bus_type *subsys,
+ const struct attribute_group **groups,
+ struct kobject *parent_of_root)
{
struct device *dev;
int err;
@@ -1243,7 +1227,7 @@ int subsys_system_register(struct bus_type *subsys,
if (err 0)
goto err_name;
- dev-kobj.parent = system_kset-kobj;
+ dev-kobj.parent = parent_of_root;
dev-groups = groups;
dev-release = system_root_device_release;
@@ -1263,8 +1247,55 @@ err_dev:
bus_unregister(subsys);
return err;
}
+
+/**
+ * subsys_system_register - register a subsystem at /sys/devices/system/
+ * @subsys: system subsystem
+ * @groups: default attributes for the root device
+ *
+ * All 'system' subsystems have a /sys/devices/system/name root device
+ * with the name of the subsystem. The root device can carry subsystem-
+ * wide attributes. All registered devices are below this single root
+ * device and are named after the subsystem with a simple enumeration
+ * number appended. The registered devices are not explicitely named;
+ * only 'id' in the device needs to be set.
+ *
+ * Do not use this interface for anything new, it exists for compatibility
+ * with bad ideas only. New subsystems should use plain subsystems; and
+ * add the subsystem-wide attributes should be added to the subsystem
+ * directory itself and not some create fake root-device placed in
+ * /sys/devices/system/name.
+ */
+int subsys_system_register(struct bus_type *subsys,
+ const struct attribute_group **groups)
+{
+ return subsys_register(subsys, groups, system_kset-kobj);
+}
EXPORT_SYMBOL_GPL(subsys_system_register);
+/**
+ * subsys_virtual_register - register a subsystem at /sys/devices/virtual/
+ * @subsys: virtual subsystem
+ * @groups: default attributes for the root device
+ *
+ * All 'virtual' subsystems have a /sys/devices/system/name root device
+ * with the name of the subystem. The root device can carry subsystem-wide
+
