[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289353544.22787.49.camel@concordia>
Date: Wed, 10 Nov 2010 12:45:44 +1100
From: Michael Ellerman <michael@...erman.id.au>
To: Kay Sievers <kay.sievers@...y.org>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] perf: sysfs type id
On Wed, 2010-11-10 at 02:19 +0100, Kay Sievers wrote:
> On Wed, Nov 10, 2010 at 02:10, Michael Ellerman <michael@...erman.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@...erman.id.au>
> To: Kay Sievers <kay.sievers@...y.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@...erman.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
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists