PCI domain stuff
A message that is not in the archive (sent off-list or not yet received): 1057010214.1277.11.camel@albertc
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1057014182.4048.3887.camel@cube
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Greg KH
Quoted 1 line
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.
Signature · 3 lines
"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
Followup to: <[email protected]> By author: Matthew Wilcox <[email protected]> In newsgroup: linux.dev.kernel
Quoted 10 lines · Greg KH
Quoted 3 lines
Quoted 1 line
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
Signature · 3 lines
<[email protected]> at work, <[email protected]> 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
Quoted 3 lines · Matthew Wilcox
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).
Followup to: <[email protected]> By author: "David S. Miller" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines · Matthew Wilcox
Quoted 3 lines
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.
Quoted 8 lines
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
Signature · 3 lines
<[email protected]> at work, <[email protected]> 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
[ 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. ]
Quoted 2 lines · H. Peter Anvin
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. :-)
Quoted 5 lines · 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. ]
Unfortunately, I can't, because I never see it. One of the very few disadvantages with reading LKML via a newsreader.
Quoted 10 lines · H. Peter Anvin
Quoted 3 lines
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?
Quoted 5 lines
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
From: "H. Peter Anvin" <[email protected]>
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.
Quoted 12 lines · David S. Miller
From: "H. Peter Anvin" <[email protected]>
Date: Mon, 30 Jun 2003 23:06:52 -0700Perhaps 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
Quoted 11 lines · David S. Miller
From: "H. Peter Anvin" <[email protected]>
Date: Mon, 30 Jun 2003 23:06:52 -0700Perhaps 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
Quoted 15 lines · Andy Isaacson
Quoted 11 lines · David S. Miller
From: "H. Peter Anvin" <[email protected]>
Date: Mon, 30 Jun 2003 23:06:52 -0700Perhaps 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.
Quoted 8 lines
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=21986Perhaps 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