public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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