Followup to: <[email protected]>
By author: "David S. Miller" <[email protected]>
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
--
<[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. ]
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. :-)
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
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.
David S. Miller wrote:
> 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.
>
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
On Mon, Jun 30, 2003 at 11:03:29PM -0700, David S. Miller wrote:
> 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.
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
Andy Isaacson wrote:
> On Mon, Jun 30, 2003 at 11:03:29PM -0700, David S. Miller wrote:
>
>> 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.
>
>
> 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