linux-kernel - Re: [RFC][PATCH] perf: sysfs type id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)