Messages in this thread | | | Subject | Re: [RFC][PATCH] perf: sysfs type id | From | Michael Ellerman <> | Date | Wed, 10 Nov 2010 12:45:44 +1100 |
| |
On Wed, 2010-11-10 at 02:19 +0100, Kay Sievers wrote: > On Wed, Nov 10, 2010 at 02:10, Michael Ellerman <michael@ellerman.id.au> wrote: > > On Wed, 2010-11-10 at 01:57 +0100, Kay Sievers wrote: > >> Stay on the list please, with any possible reply. Thanks! > > > > You dropped the CC when you replied, or is my mailer being weird? > > You replied to me only: > From: Michael Ellerman <michael@ellerman.id.au> > To: Kay Sievers <kay.sievers@vrfy.org>
Because you replied to me only, or at least that's what I see at my end.
> >> On Wed, Nov 10, 2010 at 01:52, Michael Ellerman <michael@ellerman.id.au> wrote: > >> > On Wed, 2010-11-10 at 00:45 +0100, Kay Sievers wrote: > >> The pseudo-convenience device_register/device_unregister should also > >> not be used. > > > > Why are they in the tree if they shouldn't be used? > > Because they save one line and do improper error handling. > They should all be converted to device_init+device_add/device_del/device_put.
I don't see device_init(), or do you mean device_initialize()? It returns void?
> > So far you are failing to dispel my notion that sysfs is a place where > > mortals dare not tread ;) > > Oh, you are welcome to join the endless fixing rounds. Most of the > weird stuff if from people who moved to islands far away and never > touched any Linux code anymore (no kidding). :)
Yeah fair enough :)
It is a pet peeve of mine when APIs are "deprecated" but no where is that documented, least of all by using __deprecated. I guess that's because it spews warnings, maybe we need __future_deprecated or something.
> >> > And I'm looking at eg. drivers/usb/serial/bus.c as an example bus. > >> > > >> > But in my case (and I think perf too), we don't need a bus that probes > >> > etc. it's just a virtual bus that groups things, so it seems like it > >> > should be simple. > >> > > >> > Anyway I feel like I'm missing something, so hopefully you can clue me > >> > in :) > >> > >> Buses without drivers do not probe at all, they behave like classes. > > > > OK, good, that would seem to be a prerequisite for replacing the latter > > with the former. > > > > I'm just not clear on how that actually works in the code. For example I > > have a device which is on a bus (that's how it got probed), how do I > > also put it on another bus (my virtual bus replacing my class) ? > > Nothing gets probed ever, if no driver is registered. To get a device > on a bus, just assign the bus to the 'struct device' before calling > device_add, that's all.
Cool, that sounds simple enough.
> Devices can never be on two subsystems at the same time. Not with > classes, not with buses, that was never, and probably will never be > possible.
OK, I guess I'm getting my terminology wrong. My devices, which show up in /sys/class/foo are symlinks into /sys/devices/virtual/foo, so they _appear_ to be in two places.
I also see entries for example in /sys/class/scsi_disk that link into /sys/devices/pci.
cheers
[unhandled content-type:application/pgp-signature] | |