/proc/bus/pci

/proc/bus/pci

[Albert Cahalan]

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.

Re: /proc/bus/pci

[William Lee Irwin III]

On Wed, Jun 04, 2003 at 11:21:43PM -0400, Albert Cahalan wrote:
> 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

I would be happy with such an interface.


-- wli

Re: /proc/bus/pci

[Linus Torvalds]

On Wed, 4 Jun 2003, Albert Cahalan wrote:
>
> 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

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

Re: /proc/bus/pci

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   Date: Wed, 4 Jun 2003 21:23:16 -0700 (PDT)
   
   On Wed, 4 Jun 2003, Albert Cahalan wrote:
   > bus/pci/00/00.0 -> ../hose0/bus0/dev0/fn0/config-space
   
   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?

Re: /proc/bus/pci

[Albert Cahalan]

On Thu, 2003-06-05 at 00:23, Linus Torvalds wrote:
> On Wed, 4 Jun 2003, Albert Cahalan wrote:
> >
> > 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
> 
> 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.

"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".

> 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.

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.

Re: /proc/bus/pci

[David S. Miller]

   From: Albert Cahalan <albert@users.sourceforge.net>
   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).

Re: /proc/bus/pci

[Albert Cahalan]

On Thu, 2003-06-05 at 08:16, David S. Miller wrote:
>    From: Albert Cahalan <albert@users.sourceforge.net>
>    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.

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

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

No. You explained why not:

> 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 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.

Re: /proc/bus/pci

[Albert Cahalan]

On Thu, 2003-06-05 at 08:05, Albert Cahalan wrote:
> On Thu, 2003-06-05 at 00:23, Linus Torvalds wrote:
> > On Wed, 4 Jun 2003, Albert Cahalan wrote:
> > >
> > > 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
> > 
> > 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.
> 
> "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".
> 
> > 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.
> 
> 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.

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.

Re: /proc/bus/pci

[Linus Torvalds]

On Thu, 5 Jun 2003, Albert Cahalan wrote:
> 
> Some of the IBMers use "phb" instead of "hose" or "domain".

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

Re: /proc/bus/pci

[William Lee Irwin III]

On Thu, 5 Jun 2003, Albert Cahalan wrote:
>> Some of the IBMers use "phb" instead of "hose" or "domain".

On Thu, Jun 05, 2003 at 08:51:31AM -0700, Linus Torvalds wrote:
> 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?"

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

Re: /proc/bus/pci

[Benjamin Herrenschmidt]

> 
> 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.

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.

Re: /proc/bus/pci

[William Lee Irwin III]

At some point in the past, I wrote:
>> 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.

On Thu, Jun 05, 2003 at 07:23:21PM +0200, Benjamin Herrenschmidt wrote:
> 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

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

Re: /proc/bus/pci

[Riley Williams]

Hi Linus.

 > I don't know about anybody else, but to me a "hose" is a long
 > narrow conduit for water, and a "PCI hose" doesn't much make
 > sense to me.

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

Re: /proc/bus/pci

[Ross Biro]

Linus Torvalds wrote:

>A "phb" just makes me go "Whaa?"
>
>		Linus
>
Everyone knows phb stands for pointy haired boss.


Sorry, couldn't help myself.

    Ross

Re: /proc/bus/pci

[Riley Williams]

Hi Ross.

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

 > Everyone knows phb stands for pointy haired boss.

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

Re: /proc/bus/pci

[Horst von Brand]

Ross Biro <rossb@google.com> said:
> Linus Torvalds wrote:

[...]

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

> Everyone knows phb stands for pointy haired boss.

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

RE: /proc/bus/pci

[Robert White]

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: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Linus Torvalds
Sent: Thursday, June 05, 2003 8:52 AM
To: Albert Cahalan
Cc: linux-kernel; davem@redhat.com; bcollins@debian.org;
wli@holomorphy.com; tom_gall@vnet.ibm.com; anton@samba.org
Subject: Re: /proc/bus/pci



On Thu, 5 Jun 2003, Albert Cahalan wrote:
>
> Some of the IBMers use "phb" instead of "hose" or "domain".

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: /proc/bus/pci

[Linus Torvalds]

On Fri, 6 Jun 2003, Robert White wrote:
> 
> So, my heard groans for another "domain" in the computer, and I like the way
> bridge reads

"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

RE: /proc/bus/pci

[Robert White]

From: Linus Torvalds [mailto:torvalds@transmeta.com]

> 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.

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.

RE: /proc/bus/pci

[Albert Cahalan]

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.

Re: /proc/bus/pci

[Benjamin Herrenschmidt]

> 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

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.

Re: /proc/bus/pci

[Greg KH]

On Wed, Jun 04, 2003 at 11:21:43PM -0400, Albert Cahalan wrote:
> 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.

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

Re: /proc/bus/pci

[Matt Wilson]

On Thu, Jun 05, 2003 at 09:58:31AM -0700, Greg KH wrote:
> 
> 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 :)

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
msw@redhat.com
--
Matt Wilson
Manager, Base Operating Systems
Red Hat, Inc.

Re: /proc/bus/pci

[Greg KH]

On Thu, Jun 05, 2003 at 02:27:12PM -0400, Matt Wilson wrote:
> On Thu, Jun 05, 2003 at 09:58:31AM -0700, Greg KH wrote:
> > 
> > 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 :)
> 
> 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.

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

Re: /proc/bus/pci

[Julien Oster]

Linus Torvalds <torvalds@transmeta.com> writes:

Hello Linus,

> 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.

Actually... I might have a problem with it. The really large Sun
Enterprise Servers have "Dynamic System Domains", DNS is made of
"domains", there are "SCSI domains", in NIS you set up a "domain",
virtual hosts at ISPs are sometimes just referred to as "domains" (ok,
it's silly sales talk, but it's there) and I sometimes put my code
into the "public domain".

The point is: Work into some place where there are Sun Enterprise
Servers with Dynamic System Domains, SCSI, DNS, Webservers
(incl. virtual hosts) on it and NSS is set up to NIS, get told by
somebody that "a domain is experiencing problems" and start sighing.

Even better: work on some foreign code that is using all various kind
of domains and start getting crazy!

"Ah, yes, this symbol is declared as 'struct l_d_domain *ldd1' - what
f***ing kind of domain IS IT?"

Yes, there are common words with common meaning. For example, an
interrupt is in most cases basically just an interrupt. Okay, there
are different types of interrupts... hardware, software,
edge-triggered, level-triggered, XT PIC, that new MSI kind you are
currently talking about or even interrupts which have nothing to do
with the processor but are just some software implementation on a
larger application. But those are just subtypes of interrupts, they
all share common, unambigious sense.

With domains it's not that easy. A dynamic system domain is a set of
ressources, a PCI domain is a set of PCI busses, but after those it's
getting a little bit unsharp. What is a DNS domain? Simply a set of
records? But DNS is also a hierarchical system with domains in a
hierarchical organisation, which doesn't really apply to e.g. PCI. In
PCI, you don't have domains below domains, you have busses below
domains. With NIS it gets tricky: what is a NIS domain? "A set of
users, groups and various other networkwide information"? What is an
Win2k domain? "A set of... well, Active Directory stuff?"

If we start to introduce more and more domains, the time will come
where our world is full of domains - and we long lost track of what
domains belong to what.

> 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.

I agree there, "hose" just sounds strange and also doesn't make much
sense to me. Is it pouring spashes data into my PCI cards or what does
that word try to explain?

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

But people doing computer stuff *love* abbrevations. Ask any
non-kernel-developer (or non-kernel-interested) about ACPI, MSI, MSWR,
MTRR, APIC, IO-APIC, TSC, PTE or XT-PIC-IRQ and he will not only go
"Whaa?" but "WHAAAAHELP!" :-)

Eliminate all strange sounding and unobvious abbrevation from the
kernel source and the size will at least double ;-)

Even (or even especially) the most cryptic abbrevation helps
establishing some sort of unambiguousness. Those who need to know will
know, those who don't won't care.

I for my part would love to have "phb" instead of "domain" in the
kernel. Since everytime I'll get a message from kernel that says
something about "phb", I'm just gonna say "Aaah, it's PCI". If it just
states something about a "domain", I'll just gonna yell "WHAT KIND OF
DOMAIN, YOU **&%&/".

Just my 0.02 eurocents - it's your kernel

Regards,
Julien

Re: /proc/bus/pci

[Mike Dresser]

On Thu, 5 Jun 2003, Julien Oster wrote:

> If we start to introduce more and more domains, the time will come
> where our world is full of domains - and we long lost track of what
> domains belong to what.

Don't forget that the land of Herdthinners (www.herdthinners.com) is
called "Domain" as well!

:D

Mike

Re: /proc/bus/pci

[Richard B. Johnson]

On Thu, 5 Jun 2003, Julien Oster wrote:

> Linus Torvalds <torvalds@transmeta.com> writes:
>
> Hello Linus,
>
> > 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.
>
> Actually... I might have a problem with it. The really large Sun
> Enterprise Servers have "Dynamic System Domains", DNS is made of
> "domains", there are "SCSI domains", in NIS you set up a "domain",
> virtual hosts at ISPs are sometimes just referred to as "domains" (ok,
> it's silly sales talk, but it's there) and I sometimes put my code
> into the "public domain".

[SNIPPED...]

I looked up domain in the dictionary and my eyes fell upon
diatribe, which I think describes the most common use of "domain".
Whatever happened to the word "group"? Why don't people just use
the word that was invented to represent commonality? Why do they
have to be "creative" and use words that are way out of context?

> Julien

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

RE: /proc/bus/pci

[Robert White]

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Richard B.
Johnson

> I looked up domain in the dictionary and my eyes fell upon
> diatribe, which I think describes the most common use of "domain".
> Whatever happened to the word "group"? Why don't people just use
> the word that was invented to represent commonality? Why do they
> have to be "creative" and use words that are way out of context?

I am fairly certain we are still paying the penalty for letting the
mathematicians have the first crack at computing back in the pre-history.

"Domain of the problem yields a range of solutions" and all its variations
makes "domain" from the "wonderful world of set theory" come creeping up in
all of its forms.

I myself am guilty of talking about the "domain of a problem" and I reek at
math... 8-)

Rob.

Re: /proc/bus/pci

[Michal Jaegermann]

On Thu, Jun 05, 2003 at 06:41:10PM +0200, Julien Oster wrote:
> Linus Torvalds <torvalds@transmeta.com> writes:
> 
> > A "phb" just makes me go "Whaa?"
> 
> But people doing computer stuff *love* abbrevations. Ask any
> non-kernel-developer (or non-kernel-interested) about ACPI, MSI, MSWR,
> MTRR, APIC, IO-APIC, TSC, PTE or XT-PIC-IRQ and he will not only go
> "Whaa?" but "WHAAAAHELP!" :-)

In a message from 2nd of July, here on lkml, Andre Hedrick wrote

<quote>
I need to sit down with JG, AC, BZ, JA and work out a TF <> FIS lib
for First Party DMA.
    
I need to rip the SATA 1.0 out of drivers/ide/* ...
....
    
Obviously TCQ in FPDMA via direct FIS will map to SCSI with less
pain.
    
I have FPDMA cores.
</quote>

In the first moment I started to wonder if this is a spoof; but
after a while I decided that likely it is not.  Still a translator
could be handy or it is time to update V.E.R.A. :-)

  Michal

Re: /proc/bus/pci

[Andre Hedrick]

JG Jeff Garzik
AC Alan Cox
BZ Bartlomiej Zolnierkiewicz
JA Jens Axboe

TF TaskFile
FIS Frame Information Structure

TCQ erm ... obvious
FPDMA First Party Direct Memory Access

SATA erm ... obvious
SCSI erm ... obvious

Cheers


Andre Hedrick
LAD Storage Consulting Group

On Thu, 5 Jun 2003, Michal Jaegermann wrote:

> On Thu, Jun 05, 2003 at 06:41:10PM +0200, Julien Oster wrote:
> > Linus Torvalds <torvalds@transmeta.com> writes:
> > 
> > > A "phb" just makes me go "Whaa?"
> > 
> > But people doing computer stuff *love* abbrevations. Ask any
> > non-kernel-developer (or non-kernel-interested) about ACPI, MSI, MSWR,
> > MTRR, APIC, IO-APIC, TSC, PTE or XT-PIC-IRQ and he will not only go
> > "Whaa?" but "WHAAAAHELP!" :-)
> 
> In a message from 2nd of July, here on lkml, Andre Hedrick wrote
> 
> <quote>
> I need to sit down with JG, AC, BZ, JA and work out a TF <> FIS lib
> for First Party DMA.
>     
> I need to rip the SATA 1.0 out of drivers/ide/* ...
> ....
>     
> Obviously TCQ in FPDMA via direct FIS will map to SCSI with less
> pain.
>     
> I have FPDMA cores.
> </quote>
> 
> In the first moment I started to wonder if this is a spoof; but
> after a while I decided that likely it is not.  Still a translator
> could be handy or it is time to update V.E.R.A. :-)
> 
>   Michal
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: /proc/bus/pci

[Riley Williams]

Hi Andre.

 > JG Jeff Garzik
 > AC Alan Cox
 > BZ Bartlomiej Zolnierkiewicz
 > JA Jens Axboe
 >
 > TF TaskFile
 > FIS Frame Information Structure
 >
 > TCQ erm ... obvious

TCQ = Tank Commander's Quarters

I've no idea what it stands for in Linux-Kernel. It must mean
something important though, as it comes up so regularly.

 > FPDMA First Party Direct Memory Access
 >
 > SATA erm ... obvious

SATA  = Serial ATA
PATA  = Parallel ATA
ATAPI = ATA Programming Interface

Question: What's ATA ??? I've no idea.

 > SCSI erm ... obvious

SCSI = Small Computer Systems Interface
IDE  = Integrated Drive Electronics
MFM  = Modified Frequency Modulation (ST-506)
RLL  = Run Length Limited (ST-506)

All forms of hard disk interface - that I do know.

ST-506 = Seagate Technology model 506 hard drive
         (which set the MFM and RLL standards)

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

Re: /proc/bus/pci

[Olivier Galibert]

On Fri, Jun 13, 2003 at 08:10:32AM +0100, Riley Williams wrote:
> TCQ = Tank Commander's Quarters
> 
> I've no idea what it stands for in Linux-Kernel. It must mean
> something important though, as it comes up so regularly.

Tagged Command Queuing.

> Question: What's ATA ??? I've no idea.

(IBM PC/)AT Attachment

  OG.

Re: /proc/bus/pci

[Mr. James W. Laferriere]

	Hello Riley ,

On Fri, 13 Jun 2003, Riley Williams wrote:
> Hi Andre.
...snip...
> All forms of hard disk interface - that I do know.
>
> ST-506 = Seagate Technology model 506 hard drive
>          (which set the MFM and RLL standards)
	st506 was ONLY mfm .  There were no st506 drive that had RLL
	encodings .

> ---
>  * Nothing as pretty as a smile, nothing as ugly as a frown.
	;-) ,  Twyl ,  JimL
-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

RE: /proc/bus/pci

[Riley Williams]

Hi James.

 >> All forms of hard disk interface - that I do know.
 >>
 >> ST-506 = Seagate Technology model 506 hard drive
 >>          (which set the MFM and RLL standards)

 >	st506 was ONLY mfm. There were no st506 drive that had
 >	RLL encodings.

Curiously enough, my first hard drive was an ST-506 used with
an RLL controller for the usual 45% increase in capacity. All
I can say is that it worked fine from when I bought it new
(for £350.00) through to when I had to replace the (genuine
IBM) PC/XT motherboard after it failed.

The new motherboard was a 386dx/25 and had on-board IDE and
related, so I had to get an IDE drive at the same time.

Oh - yes, I was shocked at the speed difference between the
two systems. Then again, who wouldn't be...

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

RE: /proc/bus/pci

[Mr. James W. Laferriere]

	Hello Riley ,

On Fri, 13 Jun 2003, Riley Williams wrote:
> Hi James.
>  >> All forms of hard disk interface - that I do know.
>  >> ST-506 = Seagate Technology model 506 hard drive
>  >>          (which set the MFM and RLL standards)
>  >	st506 was ONLY mfm. There were no st506 drive that had
>  >	RLL encodings.

> Curiously enough, my first hard drive was an ST-506 used with
> an RLL controller for the usual 45% increase in capacity. All
> I can say is that it worked fine from when I bought it new
> (for £350.00) through to when I had to replace the (genuine
> IBM) PC/XT motherboard after it failed.
	Yes ,  After formatting it on an RLL based controller .
	Also 'some' of the RLL controllers would recognise a st506
	mfm formatted drive & use it .
	To the best of my knowledge there never was an Segate labeled
	st-506 that was RLL encoded .

> The new motherboard was a 386dx/25 and had on-board IDE and
> related, so I had to get an IDE drive at the same time.
	Yeah I can understand that one .  Did you use the rll controller
	to transfer the data ? or ?

> Oh - yes, I was shocked at the speed difference between the
> two systems. Then again, who wouldn't be...
	YES !!! ,  Of course I was quite happily suprised at the speed
	differance found going from DEC RL02's to those st506's ;-) .
		Twyl ,  JimL
-- 
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

RE: /proc/bus/pci

[Grover, Andrew]

What about "PCI segment"?

Another overloaded CS word but it's certainly better than some of the
alternatives below. It's also the only one that is actually used in a
relevant specification (the ACPI spec.)

Regards - Andy

> -----Original Message-----
> From: Robert White [mailto:rwhite@casabyte.com] 
> Sent: Friday, June 06, 2003 5:25 PM
> To: Linus Torvalds; Albert Cahalan
> Cc: linux-kernel; davem@redhat.com; bcollins@debian.org; 
> wli@holomorphy.com; tom_gall@vnet.ibm.com; anton@samba.org
> Subject: RE: /proc/bus/pci
> 
> 
> 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: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Linus Torvalds
> Sent: Thursday, June 05, 2003 8:52 AM
> To: Albert Cahalan
> Cc: linux-kernel; davem@redhat.com; bcollins@debian.org;
> wli@holomorphy.com; tom_gall@vnet.ibm.com; anton@samba.org
> Subject: Re: /proc/bus/pci
> 
> 
> 
> On Thu, 5 Jun 2003, Albert Cahalan wrote:
> >
> > Some of the IBMers use "phb" instead of "hose" or "domain".
> 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>