Re: PCI domain stuff

Re: PCI domain stuff

[Matthew Wilcox]

On Mon, Jun 30, 2003 at 04:15:15PM -0700, Greg KH wrote:
> > AFAIK, sysfs won't support mmap.
> 
> What do you want to mmap?  The PCI config space?

We need to support mmaping device resources.  I think this actually
merits being a first class sysfs concept -- turn a struct resource into
an mmapable file.  The current fugly ioctl really has to go.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: PCI domain stuff

[H. Peter Anvin]

Followup to:  <20030701040531.GB23597@parcelfarce.linux.theplanet.co.uk>
By author:    Matthew Wilcox <willy@debian.org>
In newsgroup: linux.dev.kernel
>
> On Mon, Jun 30, 2003 at 04:15:15PM -0700, Greg KH wrote:
> > > AFAIK, sysfs won't support mmap.
> > 
> > What do you want to mmap?  The PCI config space?
> 
> We need to support mmaping device resources.  I think this actually
> merits being a first class sysfs concept -- turn a struct resource into
> an mmapable file.  The current fugly ioctl really has to go.
> 

mmapping can be extremely expensive, though, if the data is expensive
to generate.  It also has concurrency issues if things can change and
data can cross page boundaries.

      -hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: PCI domain stuff

[David S. Miller]

On Mon, 2003-06-30 at 21:05, Matthew Wilcox wrote:
> We need to support mmaping device resources.  I think this actually
> merits being a first class sysfs concept -- turn a struct resource into
> an mmapable file.  The current fugly ioctl really has to go.

What's so wrong with the "fugly ioctl"?

What can't you do with it?

You can even mmap the complete I/O space of a PCI bus (in order to poke
around in implicit I/O resources like the VGA registers that a PCI card
might respond to).

Re: PCI domain stuff

[H. Peter Anvin]

Followup to:  <1057034041.31826.1.camel@rth.ninka.net>
By author:    "David S. Miller" <davem@redhat.com>
In newsgroup: linux.dev.kernel
>
> On Mon, 2003-06-30 at 21:05, Matthew Wilcox wrote:
> > We need to support mmaping device resources.  I think this actually
> > merits being a first class sysfs concept -- turn a struct resource into
> > an mmapable file.  The current fugly ioctl really has to go.
> 
> What's so wrong with the "fugly ioctl"?
> 
> What can't you do with it?
> 
> You can even mmap the complete I/O space of a PCI bus (in order to poke
> around in implicit I/O resources like the VGA registers that a PCI card
> might respond to).
> 

Presumably only on architectures which use memory-mapped IO address
space.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: PCI domain stuff

[David S. Miller]

[ Pater, please retain the CC: list in your replies.  I scan
linux-kernel casually at best, and I probably would have missed
this reply of yours under normal circumstances, if you had retained
the CC: list I would have read it via my non-lkml account and therefore
not have missed it. ]

On Mon, 2003-06-30 at 22:47, H. Peter Anvin wrote:
> Presumably only on architectures which use memory-mapped IO address
> space.

On ones that don't we use the x86's existing facilities for doing
this, ioperm() and direct I/O instructions.

These issues are platform dependant for other reasons anyways
(endianness, barrier instructions needed, etc.)

But everything the most demanding testcase in userspace needs (this
being xfree86) needs can be done with the existing facilities.

Unlike other people, I do not see the value in having 50 ways to
do the same thing. :-)

Re: PCI domain stuff

[H. Peter Anvin]

David S. Miller wrote:
> [ Pater, please retain the CC: list in your replies.  I scan
> linux-kernel casually at best, and I probably would have missed
> this reply of yours under normal circumstances, if you had retained
> the CC: list I would have read it via my non-lkml account and therefore
> not have missed it. ]

Unfortunately, I can't, because I never see it.  One of the very few 
disadvantages with reading LKML via a newsreader.

> On Mon, 2003-06-30 at 22:47, H. Peter Anvin wrote:
> 
>>Presumably only on architectures which use memory-mapped IO address
>>space.
> 
> On ones that don't we use the x86's existing facilities for doing
> this, ioperm() and direct I/O instructions.
> 
> These issues are platform dependant for other reasons anyways
> (endianness, barrier instructions needed, etc.)

Right.  As long as this is clear to people; I'm not sure it always is.

Perhaps a libdirectio would be useful?

> But everything the most demanding testcase in userspace needs (this
> being xfree86) needs can be done with the existing facilities.
> 
> Unlike other people, I do not see the value in having 50 ways to
> do the same thing. :-)

Agreed with that, *as long as* the implementation is sane.

	-hpa

Re: PCI domain stuff

[David S. Miller]

   From: "H. Peter Anvin" <hpa@zytor.com>
   Date: Mon, 30 Jun 2003 23:06:52 -0700

   Perhaps a libdirectio would be useful?
   
The details are very PCI specific, so what you'd be working
on initially is a PCI centric library.

Over time things can be abstracted, but the initial PCI specific
one would be good enough for xfree86 to link to and make use
of which is a huge step in the right direction.

Re: PCI domain stuff

[H. Peter Anvin]

David S. Miller wrote:
>    From: "H. Peter Anvin" <hpa@zytor.com>
>    Date: Mon, 30 Jun 2003 23:06:52 -0700
> 
>    Perhaps a libdirectio would be useful?
>    
> The details are very PCI specific, so what you'd be working
> on initially is a PCI centric library.
> 
> Over time things can be abstracted, but the initial PCI specific
> one would be good enough for xfree86 to link to and make use
> of which is a huge step in the right direction.
 >

Well, "PCI" in this case presumably means 
PCI/PCI-X/PCI-Express/AGP/HyperTransport, which covers an amazing number 
of the machines actually being used these days.  Obviously it doesn't 
apply to all, but as you say, it can be abstracted on over time.

	-hpa

Re: PCI domain stuff

[Andy Isaacson]

On Mon, Jun 30, 2003 at 11:03:29PM -0700, David S. Miller wrote:
>    From: "H. Peter Anvin" <hpa@zytor.com>
>    Date: Mon, 30 Jun 2003 23:06:52 -0700
> 
>    Perhaps a libdirectio would be useful?
>    
> The details are very PCI specific, so what you'd be working
> on initially is a PCI centric library.
> 
> Over time things can be abstracted, but the initial PCI specific
> one would be good enough for xfree86 to link to and make use
> of which is a huge step in the right direction.

There is some interest in the NetBSD project for such an API, as well.
<fair at netbsd.org> filed xsrc/21986 last week.
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=21986

Perhaps a common implementation could develop.

(OK, I can dream...)

-andy

Re: PCI domain stuff

[H. Peter Anvin]

Andy Isaacson wrote:
> On Mon, Jun 30, 2003 at 11:03:29PM -0700, David S. Miller wrote:
> 
>>   From: "H. Peter Anvin" <hpa@zytor.com>
>>   Date: Mon, 30 Jun 2003 23:06:52 -0700
>>
>>   Perhaps a libdirectio would be useful?
>>   
>>The details are very PCI specific, so what you'd be working
>>on initially is a PCI centric library.
>>
>>Over time things can be abstracted, but the initial PCI specific
>>one would be good enough for xfree86 to link to and make use
>>of which is a huge step in the right direction.
> 
> 
> There is some interest in the NetBSD project for such an API, as well.
> <fair at netbsd.org> filed xsrc/21986 last week.
> http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=21986
> 
> Perhaps a common implementation could develop.
> 
> (OK, I can dream...)
> 

Right, and the article brings up a particularly nasty issue -- PCI 
probing from userspace is dangerous as it's inherently not atomic.  That 
really *is* the kernel's job, and abstracting that via a library would 
make it a lot less obnoxious from XFree86's standpoint.

	-hpa