From: Greg KH <greg@kroah.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ryan Arnold <rsa@us.ibm.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Dave Boutcher <sleddog@us.ibm.com>
Subject: Re: device/kobject naming
Date: Wed, 25 Feb 2004 16:18:31 -0800 [thread overview]
Message-ID: <20040226001830.GB3702@kroah.com> (raw)
In-Reply-To: <C4149BD3-67A9-11D8-B826-000A95A0560C@us.ibm.com>
On Wed, Feb 25, 2004 at 09:46:24AM -0600, Hollis Blanchard wrote:
> On Feb 25, 2004, at 5:34 AM, Benjamin Herrenschmidt wrote:
> >On Wed, 2004-02-25 at 15:22, Greg KH wrote:
> >>I agree. Is there any reason we _have_ to stick with the OF names?
> >>It
> >>seems to me to make more sense here not to, to make it more like the
> >>rest of the kernel.
> >>
> >>That is, if the address after the @ is unique. Is that always the
> >>case?
> >
> >One thing though is that it's only unique at a given level of
> >hierarchy. The Unit Address in OF has no meaning outside of the
> >context of the parent bus. That may be just fine for sysfs, but
> >if I take as an example the PCI devices, they do have a globally
> >unique ID here with the domain number.
>
> Yes, that's certainly the case. Every unit address on the virtual bus
> will be unique, but device_add() uses dev.bus_id as the kobject name,
> which is system-wide.
>
> Apparently PCI gets away with multiple busses by encoding the domain
> and bus IDs into dev.bus_id along with the slot number. Even then, it's
> just kind of coincidence that nothing else wants to register kobjects
> with names like 0000:00:0b.0, right? Unless we want to start defining
> mandatory "domains" for every type of device and prefixing things like
> that...
No, I think you are confused. The only thing that has to be unique in
the kobject/device name is it must be unique for the bus it is on.
So for PCI we encode the domain and bus id into .bus_id as we know it
will be unique on this system. There is no "coincidence" involved at
all. Same thing with USB, and all other busses. You only have to be
unique for your specific bus.
So for this bus, that is all that is needed. You don't have to worry
about the PCI/USB/FooBUS namespace at all.
> At any rate, virtual IO devices effectively have just a slot number and
> nothing else. Do you really want to start registering kobjects with
> names like "30000000"?
Why not? We do it for every other bus type.
> Or what about "vio:30000000", and then have it show up as
> "/sys/devices/vio/vio:30000000"? Seems redundant to me.
Exactly, it is redundant. That's why you don't need the "vio:" portion.
Does this help out?
thanks,
greg k-h
next prev parent reply other threads:[~2004-02-26 0:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 0:00 new driver (hvcs) review request and sysfs questions Ryan Arnold
2004-02-25 1:28 ` Greg KH
2004-02-25 3:12 ` Dave Boutcher
2004-02-25 4:22 ` Greg KH
2004-02-25 11:34 ` Benjamin Herrenschmidt
2004-02-25 15:46 ` device/kobject naming Hollis Blanchard
2004-02-26 0:18 ` Greg KH [this message]
2004-02-26 21:31 ` Hollis Blanchard
2004-02-25 16:22 ` new driver (hvcs) review request and sysfs questions Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040226001830.GB3702@kroah.com \
--to=greg@kroah.com \
--cc=benh@kernel.crashing.org \
--cc=hollisb@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rsa@us.ibm.com \
--cc=sleddog@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox