[parisc-linux] sys/io.h

[parisc-linux] sys/io.h

[Grant Grundler]

Hi,
I'm trying to build tulip-diag.c from scyld.com and am getting the
following error msg:
gsyprf11:~# gcc -O tulip-diag.c -o tulip-diag
tulip-diag.c:58:20: sys/io.h: No such file or directory
tulip-diag.c:1347:24: warning: multi-line string literals are deprecated

On ia64, sys/io.h comes from
gsyprf3:~# dpkg -S sys/io.h
libc6.1-dev: /usr/include/sys/io.h

But we don't have the equivalent for parisc (hppa).
Ideas?

thanks,
grant

Re: [parisc-linux] sys/io.h

[Randolph Chung]

> I'm trying to build tulip-diag.c from scyld.com and am getting the
> following error msg:
> gsyprf11:~# gcc -O tulip-diag.c -o tulip-diag
> tulip-diag.c:58:20: sys/io.h: No such file or directory
> tulip-diag.c:1347:24: warning: multi-line string literals are deprecated
> 
> On ia64, sys/io.h comes from
> gsyprf3:~# dpkg -S sys/io.h
> libc6.1-dev: /usr/include/sys/io.h
> 
> But we don't have the equivalent for parisc (hppa).
> Ideas?

ISTR this has to do with the fact that we do not want to/cannot expose 
the {in,out}[bwl] primitives to userspace. Is the tulip-diag program
trying to write to port space directly?

FWIW we have the same problems with things like sane. 

ia64 seems to have some wrappers in glibc to do port io....

randolph

Re: [parisc-linux] sys/io.h

[Jes Sorensen]

>>>>> "Randolph" == Randolph Chung <tausq@debian.org> writes:

>> I'm trying to build tulip-diag.c from scyld.com and am getting the
>> following error msg: gsyprf11:~# gcc -O tulip-diag.c -o tulip-diag
>> tulip-diag.c:58:20: sys/io.h: No such file or directory
>> tulip-diag.c:1347:24: warning: multi-line string literals are
>> deprecated
>> 
>> On ia64, sys/io.h comes from gsyprf3:~# dpkg -S sys/io.h
>> libc6.1-dev: /usr/include/sys/io.h
>> 
>> But we don't have the equivalent for parisc (hppa).  Ideas?

Randolph> ISTR this has to do with the fact that we do not want
Randolph> to/cannot expose the {in,out}[bwl] primitives to
Randolph> userspace. Is the tulip-diag program trying to write to port
Randolph> space directly?

You really should support it similar to what we do on
ia64. Ie. there's a Linux API here that allows you to map 'I/O' ports
and access them. Basing the code on what's in the ia64 glibc tree
would make it quite easy to get it up and running.

Jes

Re: [parisc-linux] sys/io.h

[Matthew Wilcox]

On Tue, Jun 25, 2002 at 12:18:31PM -0400, Jes Sorensen wrote:
> You really should support it similar to what we do on
> ia64. Ie. there's a Linux API here that allows you to map 'I/O' ports
> and access them. Basing the code on what's in the ia64 glibc tree
> would make it quite easy to get it up and running.

Um, we can't.  To do a port space access on Dino is:

acquire spin lock
write address to register
perform read or write access to a different register
release spin lock

i do hope you're not about to suggest emulating the proposed interface
by unmapping an address range and handling this in the fault handler

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] sys/io.h

[Grant Grundler]

Jes Sorensen wrote:
> You really should support it similar to what we do on
> ia64. Ie. there's a Linux API here that allows you to map 'I/O' ports
> and access them. Basing the code on what's in the ia64 glibc tree
> would make it quite easy to get it up and running.

I don't think so. For two reasons:
a) ia64 maps the "iobase" address to user space
b) the ia64 method is fixed for the architecture on how
   to generate "legacy" IO port cycles (using iobase).

parisc has two different methods (dino vs elroy) and dino only
supports poking the PCI HBA to generate IO Port cycles.
Or am I over looking something?

grant

Re: [parisc-linux] sys/io.h

[Jes Sorensen]

>>>>> "Matthew" == Matthew Wilcox <willy@debian.org> writes:

Matthew> On Tue, Jun 25, 2002 at 12:18:31PM -0400, Jes Sorensen wrote:
>> You really should support it similar to what we do on
>> ia64. Ie. there's a Linux API here that allows you to map 'I/O'
>> ports and access them. Basing the code on what's in the ia64 glibc
>> tree would make it quite easy to get it up and running.

Matthew> Um, we can't.  To do a port space access on Dino is:

Matthew> acquire spin lock write address to register perform read or
Matthew> write access to a different register release spin lock

Matthew> i do hope you're not about to suggest emulating the proposed
Matthew> interface by unmapping an address range and handling this in
Matthew> the fault handler

Well then make it a syscall and do it in the kernel - yes it's not
pretty but if the architecture requires it then thats the way to get
around it.

Jes

Re: [parisc-linux] sys/io.h

[Jes Sorensen]

>>>>> "Jes" == Jes Sorensen <jes@trained-monkey.org> writes:

Jes> Well then make it a syscall and do it in the kernel - yes it's
Jes> not pretty but if the architecture requires it then thats the way
Jes> to get around it.

Let me elaborate:

When the hardware is evil as you described in your mail, then it has
to go by the kernel. However if you have multiple cases, like Grant
mentioned Elroy vs Dino? then glibc can do a test the first time the
operation is done and cache that in userland for next time a request
is done - ie. when you're running on the type of hw that can do it in
userland then you don't have to go by the kernel except for the first
time.

Jes