[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130302202615.GA3678@htj.dyndns.org>
Date: Sat, 2 Mar 2013 12:26:15 -0800
From: Tejun Heo <tj@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, laijs@...fujitsu.com,
axboe@...nel.dk, jmoyer@...hat.com, zab@...hat.com,
Kay Sievers <kay.sievers@...y.org>
Subject: 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists