On Mon, 2003-07-14 at 00:53, Greg KH wrote:
> On Sun, Jul 13, 2003 at 11:51:48PM -0400, Albert Cahalan wrote:
> > The existing /proc/bus/pci/*/* files are a
> > hack involving ioctl and out-of-bounds mmap.
> > The following patch starts a transition to
> > something sane while keeping compatibility.
> > 
> > Typical user-space drivers for polled devices
> > should be easy to port to the new interface.
> > The X server will need some per-arch enhancements
> > to handle write-combining (non-x86 lack MTRRs)
> > and the use of multiple VGA-style devices.
> > 
> > In the new interface, pci/00/00.0 is a symbolic
> > link to a ../../pci*/bus0/dev0/fn0/config-space
> > file, where the '*' is typically 0. (PCI domain)
> > Simple and direct per-resource mmap() is provided,
> > via pci0/bus0/dev0/fn0/bar0 and so on.
> 
> Why put all of these extra directories in /proc?  We talked about this
> before...
>
> What are you trying to "transition to"?  What do you want to see this
> look like when you are finished?

The directory structure may well be finished,
at least until it is time to remove the old
interfaces. (in a few years I guess)

What's missing is the ability to pass cache-control
info through the mmap() interface. This is useful
for non-PCI purposes as well. Some thought will be
required, as there is a set of commonly useful
settings among all the arch-specific features.

> And are you prepared to patch all of
> the userspace programs that currently rely on the existing interface
> (like XFree86 for one)?

The existing interface STILL WORKS. Apps can
transition over time, in part or in whole.
("in part" meaning to use the old hacks on
the new pathname, gaining PCI domain support)

It's important to get the new interface in
ASAP, so that all the obscure (in-house, etc.)
user-space drivers can start to transition.
The X server is less of a worry, because it
is a very active project.

> Also, I don't think you are handling the pci domain space in your patch,
> or am I just missing it?

You missed it: third paragraph, first email

Example:
You have two devices with the same bus
number (5), device number (4), and function
number (2). One is in domain 0, and the
other is in domain 42. You get:

pci0/bus5/dev4/fn2/config-space
pci42/bus5/dev4/fn2/config-space

Depending on what pci_name_bus does with
the conflict, you'll get one or two symlinks
from the old name(s). You'll also get some
correctly-sized files to represent the
resources. For example:

pci0/bus5/dev4/fn2/bar0
pci0/bus5/dev4/fn2/bar1
pci0/bus5/dev4/fn2/bar2
pci42/bus5/dev4/fn2/bar0

> And your patch was linewrapped :)

Damn. I thought only the local display was messed up.
Anybody know how to make Evolution behave?
Here's an attachment: