/proc/bus/pci

I notice that /proc/bus/pci doesn't offer a sane interface for multiple PCI domains and choice of BAR. What do people think of this?

bus/pci/00/00.0 -> ../hose0/bus0/dev0/fn0/config-space bus/pci/hose0/bus0/dev0/fn0/config-space bus/pci/hose0/bus0/dev0/fn0/bar0 bus/pci/hose0/bus0/dev0/fn0/bar1 bus/pci/hose0/bus0/dev0/fn0/bar2 bus/pci/hose0/bus0/dev0/fn0/status

Then with some mmap flags, the nasty ioctl() stuff won't be needed anymore. It can die during 2.7.xx development. If MAP_MMIO isn't generally acceptable, then it could be via filename suffixes. (eeew, IMHO)

One remaining problem is permission. Any complaints about implementing chmod() for those? Since this does bypass capabilities, a mount option might be used to enable it.

As alternatives to /proc changes, a distinct filesystem could be developed or sysfs could be abused.

I would be happy with such an interface.

-- wli

Why do we have that stupid "hose" name? Only because of strange alpha naming, or did somebody else also use that incredibly silly name?

Please talk about "domains", at least it makes some sense as a name.

I'm also hoping that /proc/bus will eventually go away, so I don't see a major problem with not understanding multiple domains at that level.

On a /sys/bus/xxx level we actually should already be able to handle multiple domains, but the naming is broken. However, in /sys we should be able to nicely handling non-zero domains by just extending the name space a bit.

Linus

From: Linus Torvalds <[email protected]>
Date: Wed, 4 Jun 2003 21:23:16 -0700 (PDT)

Why do we have that stupid "hose" name? Only because of strange alpha naming, or did somebody else also use that incredibly silly name?

Please talk about "domains", at least it makes some sense as a name.

I agree.

I'm also hoping that /proc/bus will eventually go away, so I don't see a major problem with not understanding multiple domains at that level.

On a /sys/bus/xxx level we actually should already be able to handle multiple domains, but the naming is broken. However, in /sys we should be able to nicely handling non-zero domains by just extending the name space a bit.

My only concern is what file lookup algorithm we should be encouraging things like xfree86 to use. Check /sys then /proc/bus?

"hose" does sound pretty crazy, but...

a. "domain" is way overused in OSes and programming
b. "hose" is short
c. with old names like "d4", "hose" is better for tab-completion

I'm sure somebody could name a dozen things called "domain".

Does this mean you'd like to see per-BAR kobject stuff? If I'm not mistaken, that is required for sysfs to work.

So sysfs then has:

devices/pci2/02:0b.0 -> ../hose0/bus2/dev11/fn0 devices/hose0/bus2/dev11/fn0/config-space devices/hose0/bus2/dev11/fn0/bar0 devices/hose0/bus2/dev11/fn0/bar1 devices/hose0/bus2/dev11/fn0/bar2 devices/hose0/bus2/dev11/fn0/class devices/hose0/bus2/dev11/fn0/power devices/hose0/bus2/dev11/fn0/subsystem_vendor devices/hose0/bus2/dev11/fn0/and-so-on

To make this clear, mmap() on bar0 would get you a mapping of that BAR.

From: Albert Cahalan <[email protected]>
Date: Thu, 05 Jun 2003 08:05:59 -0400

To make this clear, mmap() on bar0 would get you a mapping of that BAR.

We have a way to portably mmap() PCI devices using just the device node.

If you make this new method, you might have to define a whole new set of arch level support hooks.

What I'm saying is, we should reuse all of this code we have to support mmap()'ing PCI devices properly now (via procfs device node files).

The "device node"? You mean stuff in /proc, right?

No. You explained why not:

The existing per-arch code looks like it would work. At worst, an offset (probably already a #define somewhere) might need to be added.

Pushing a MAP_MMIO through to the per-arch code might be slightly more involved. I can do PowerPC and x86 at least, if it comes to that.

Some of the IBMers use "phb" instead of "hose" or "domain". It's Primary Host Bridge, which can only be confused with Pointy-Haired Boss AFAIK.

Gods, did they run out of vowels in _that_ part of IBM too?

Where do they go? Is there somebody at IBM that hoards vowels, and will one day hold the rest of the world hostage? "Mwahahahaa! If you don't buy support from IBM, you can never use the letter 'A' again! Whahahahhhaah!".

I can see it now.

What the _f*ck_ is wrong with just calling it "PCI domain". It's a fine word, and yes, "domain" is used commonly in computer language, but that's a _good_ thing. Everybody immediately understands what it is about.

There is no goodness to acronyms where you have to be some "insider" to know what the hell it means. That "hose" thing has the same problem: I don't know about anybody else, but to me a "hose" is a logn narrow conduit for water, and a "PCI hose" doesn't much make sense to me.

A "phb" just makes me go "Whaa?"

Linus

I've never seen this; however, I've seen "PCI segment" used in some Intel docs. I do agree that neither "phb" nor "hose" are particularly nice nomenclature.

-- wli

imho, calling a domain a "segment" is plain wrong, I'd rather call "segment" a single electrical PCI bus ...

Note: I'm to blame for polluting ppc32 with the "hose" name in variable/function names =P

Ben.

I wouldn't particularly advocate segment over anything, I've merely seen it used. I think we're all happy with "domain" (and are more concerned with the functional issues anyway).

-- wli

Hi Linus.

To me a "PCI hose" is a device used on one of these new-fangled water-cooled systems to cool down an overheated PCI bus somewhere. Any other use is, at best, broken...

Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 1-Jun-2003

Everyone knows phb stands for pointy haired boss.

Sorry, couldn't help myself.

Ross

Hi Ross.

I didn't - I always thought it stood for Pointless Hacker's Boasts...

Also, isn't this getting off-topic here ???

Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.488 / Virus Database: 287 - Release Date: 5-Jun-2003

[...]

Then Linus is absolutely right ;-)

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

My Humble Opinion:

"hose0" -> bad, I know I didn't have a clue where it came from

"domain0" -> obscure but mathematical 8-), probably hard to teach what with the name used all over heck

"phb0" -> "eh what is phb?" "primary host bridge"...

"bridge0" -> not bad, is it platform agnostic? (e.g. is the connection called a bridge on non- Intel/AMD/PS platforms?) don't know... but if it is... good

Note: There are no "good" synonyms for "Domain" (from M-W.com:)

"field, bailiwick, champaign, demesne, dominion, province, sphere, terrain, territory, walk"

So, my heard groans for another "domain" in the computer, and I like the way bridge reads

"devices/bridge0/bus2/dev11/fn0/whatever"

but regardless (going back to pc-isms) that puts things like the pci-agp "bridge" and such into the namespace if one were to be especially conformant, which may or may not be a good thing.

Rob.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Linus Torvalds
Sent: Thursday, June 05, 2003 8:52 AM
To: Albert Cahalan
Cc: linux-kernel; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: /proc/bus/pci

Gods, did they run out of vowels in _that_ part of IBM too?

Where do they go? Is there somebody at IBM that hoards vowels, and will one day hold the rest of the world hostage? "Mwahahahaa! If you don't buy support from IBM, you can never use the letter 'A' again! Whahahahhhaah!".

I can see it now.

What the _f*ck_ is wrong with just calling it "PCI domain". It's a fine word, and yes, "domain" is used commonly in computer language, but that's a _good_ thing. Everybody immediately understands what it is about.

There is no goodness to acronyms where you have to be some "insider" to know what the hell it means. That "hose" thing has the same problem: I don't know about anybody else, but to me a "hose" is a logn narrow conduit for water, and a "PCI hose" doesn't much make sense to me.

A "phb" just makes me go "Whaa?"

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

"bridge" means something completely different in PCI, it's a hub inside a PCI domain, literally "bridging" two separate parts of the same domain more-or-less seamlessly together.

A PCI domain, in contrast, is something that is _not_ bridged to another PCI domain - two PCI domains are disjunct, and do not share any connection (PCI-wise) to each other.

(Obviously there is some _non_PCI connection, since they are in the same box, but that non-PCI connection might be the CPU, or it might be some other switching fabric that is not itself visible in the PCI space).

This is why "domain" makes sense - at least to me "domain" is a independent area as in "I am the master of my domain", correctly implying that there may be other domains, but that they are separate.

Linus

From: Linus Torvalds [mailto:[email protected]]

Yea, somebody needs to jump all over the mathematicians and get them to invent _another_ good word for "peer of the realm" style independent first order super-sets.... 8-)

Rob.

It turns out I picked up "hose" from the PowerPC code. I always thought of it as something that sprays data.

To be really clear, "superbus" is descriptive. While "bridge" is no good, "hostbridge" works.

Anyway, how about some substance?

I suppose sysfs can just change, since there wasn't a sysfs filesystem in the 2.4.xx kernels.

Fixing up /proc/bus/pci isn't terribly bad, assuming the PCI structs could hold per-bar proc filesystem entries. I hope there isn't an objection to that.

For mmap, I'm thinking this:

#define MAP_MMIO (MAP_ARCH_FOO | MAP_ARCH_BAR)

That is, MAP_MMIO is defined in terms of arch-specific flags that are appropriate for typical memory-mapped IO. The old ioctl() takes priority.

Another way to do this is via filename, which is kind of ugly but great for non-mmap usage.

The first entry (devices/pci2/....) is wrong imho.

With multiple domains, we can have several busses with the same bus number, one in each domain. So it's a matter of taking the current set of pciN entries and moving them below a "pci-domain" entry (or hose, or whatever Linus prefers).

Also, the node name for individual PCI devices must include the domain number, the current bus:dev.fn notation isn't enough, that will break things like /sys/bus/pci/devices when you have several identical bus/devfn pairs on different domains

Ben.

Matt Wilson and I have been talking about some changes like this recently. This was because some of the ppc64 ports are doing some other weird things to try to handle the bigger IBM machines (they were abusing the pci structures pretty badly, not pretty stuff.)

We agreed that we should call this a "domain", too, and he has a patch that he says works for X.

Hopefully this prod will get him to send out his patch :)

thanks,

greg k-h

it's a simple change to parsing /proc/bus/pci/devices in xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_pci.c. For the rest of pci setup, you need to write arch specific code in xc/programs/Xserver/hw/xfree86/os-support/bus/* anyway.

Cheers,

Matt
[email protected]
--
Matt Wilson
Manager, Base Operating Systems
Red Hat, Inc.

No, I meant your kernel patches that add domain support in a sane way. I don't care about X patches :)

thanks,

greg k-h