Messages in this thread | | | Date | Thu, 7 Jul 2011 12:22:41 +0200 | From | Robert Richter <> | Subject | Re: [RFC] [PATCH] perf: Attaching an event to a specific PMU |
| |
On 06.07.11 13:10:15, Ingo Molnar wrote: > > * Robert Richter <robert.richter@amd.com> wrote:
> > I have to learn yet why /dev is bad and /sys is good... > > Because /sys is already there and already carries rather rich > classification of various hardware components, devices and kernel > subsystems. > > /dev/ is mostly a flat registry of classical, unstructured devices.
As already said, /sys provides system information. Of course it is richer then. But I also don't want/need to specify a pmu that deep in the system hierarchy. And /dev is flat and easy. What of the following would you prefer?
/sys/devices/pci0000:00/0000:00:03.0/usb2/2-2/2-2:1.1/input/input4/mouse0 /dev/input/mouse0
Beside of this, you can't control devices with /sys.
> > The system topology is always in /sys, also for device nodes. But > > we can't get a device file descriptor from /sys. I doubt /sys is > > capable to handle a device use count (need to be checked). We > > actually must grab the pmu while attaching events to it. And, user > > space implementation is must easier with /dev (see code in my > > previous mail). > > I think Peter suggested it that an open() done in /sys should give us > a handle to a given event?
Using /dev solves the problems in a simple way, and simple things often work very well. With open() we control the refcount and we then get a device reference which is unique and immediately usable without parsing strings. This makes user code small and intuitive and also avoids complex config checks on the kernel side to catch wrongly assigned events.
While we probably can live with such races now on static pmus, thinking of future use cases like hotplugable graphic cards with pmus in it, we actually want a clean design for this. I don't see how to do this with sysfs. As there are no implementations yet for such an interface, we now have the chance to design it properly.
> > My patch also includes code that creates a device class. It is also > > visible in /sys/class/pmu/*. > > But PMU is a very limited term: what we want is a higher level > organization of 'event sources' and 'events'. Some may come from > PMUs, many wont.
You can see it as 'virtual' pmu, like the virtual file system. Whatever the name for this is, 'event sources' is not very handy. But don't want to change this.
-Robert
-- Advanced Micro Devices, Inc. Operating System Research Center
| |