[parisc-linux] Include trouble

[parisc-linux] Include trouble

[Thomas Marteau]

Hi folks,

	Just to know if it is a local problem. We have this warning when we
cross compile the kernel:

/linux/cvs/linux/include/linux/string.h:61: warning: conflicting types
for built-in function `memset'
/linux/cvs/linux/include/linux/string.h:64: warning: conflicting types
for built-in function `memcpy'
/linux/cvs/linux/include/linux/string.h:73: warning: conflicting types
for built-in function `memcmp'

Can we have your point of view?

Bye, ESIEE Team

Re: [parisc-linux] Include trouble

[Alan Modra]

On Mon, 27 Nov 2000, Thomas Marteau wrote:

> Can we have your point of view?

Your version of gcc expects the size_t parameter to all these functions to
be "unsigned int", whereas the 2000/11/18 changes to
linux/include/asm-parisc/posix_types.h made __kernel_size_t
"unsigned long".

As far as I understand, gcc's cpp has a built-in definition of size_t,
__SIZE_TYPE__, and it ultimately gets it's idea of the definition from the
kernel includes on the machine where gcc was compiled.  ie. recompile gcc
with the new kernel headers installed, and the problem should go away.

For 32-bit hppa-linux, sizeof(int) == sizeof(long) so there shouldn't be
any practical consequence other than these warning messages.  There might
be some "interesting" problems on hppa64-linux - I'm not sure.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Include trouble

[Alan Modra]

On Tue, 28 Nov 2000, Alan Modra wrote:

> As far as I understand, gcc's cpp has a built-in definition of size_t,
> __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the
> kernel includes on the machine where gcc was compiled.  ie. recompile gcc
> with the new kernel headers installed, and the problem should go away.

No, that's wrong.  __SIZE_TYPE__ comes from `#define SIZE_TYPE' in
gcc/config/pa/pa-linux{,64}.h  I'll check in a patch to gcc in a few
moments.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Include trouble

[John David Anglin]

> On Tue, 28 Nov 2000, Alan Modra wrote:
> 
> > As far as I understand, gcc's cpp has a built-in definition of size_t,
> > __SIZE_TYPE__, and it ultimately gets it's idea of the definition from the
> > kernel includes on the machine where gcc was compiled.  ie. recompile gcc
> > with the new kernel headers installed, and the problem should go away.
> 
> No, that's wrong.  __SIZE_TYPE__ comes from `#define SIZE_TYPE' in
> gcc/config/pa/pa-linux{,64}.h  I'll check in a patch to gcc in a few
> moments.

Hmm.  Most 32 bit systems use "unsigned int" rather than "unsigned long".
Using "unsigned long" might cause problems with packages like libio.
I know there is a problem if off_t is not the same as size_t.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Include trouble

[Paul Bame]

= Hmm.  Most 32 bit systems use "unsigned int" rather than "unsigned long".

I will be happy to change it back to unsigned int.  The only reason
I used unsigned long is because it seems off_t wants to be, to a
first approximation, the word length of the machine, and 'long' does
that.

= Using "unsigned long" might cause problems with packages like libio.


= I know there is a problem if off_t is not the same as size_t.

What problem is that?  I'm working on a proposal for the palinux
type sizes at the moment.

One dilema is that off_t is supposed to
be good for file offsets, which these days means it should be 64 bits.
size_t refers to the sizes of objects which are expected to fit in
RAM, so should be the word size of the machine.  So there's a conflict
because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux,
but your statement suggests they should be the same size.  Any ideas?

However I'm leaning towards leaning with the older 32-bit off_t because
we might not want to be the first ones to fix all the problems with
making it 64 bits on a 32-bit machine.

	-P

Re: [parisc-linux] Include trouble

[Alan Cox]

> One dilema is that off_t is supposed to
> be good for file offsets, which these days means it should be 64 bits.

off_t should be a natural type. So it should be 32bits. glibc 2.2 deals with
the 64bit I/O stuff nicely

> However I'm leaning towards leaning with the older 32-bit off_t because
> we might not want to be the first ones to fix all the problems with
> making it 64 bits on a 32-bit machine.

Go 32bit. Linus will probably refuse to touch a 32bit port using longlong
internally for off-t

Re: [parisc-linux] Include trouble

[Paul Bame]

= Go 32bit. Linus will probably refuse to touch a 32bit port using longlong
= internally for off-t

Hmmm, too bad, since we have few palinux backwards compatibility issues and
could just have the __USE_FILE_OFFSET64 glibc magic be a no-op rather
than supporting all those extra *64 syscalls.  Plus we'd need
considerably fewer syscall translators to run 32-bit apps on 64-bit
kernel (but might need more for 32-bit hpux apps).  It seems illogical
to make a file-system-related data type different based on cpu
word size but I understand this isn't simple -- oh well.

Seems like the consensus is 32-bit off_t on 32-bit kernel and just
live with all those *64 syscalls -- many not supported on palinux
yet I notice.

	-P

Re: [parisc-linux] Include trouble

[Alan Cox]

> Seems like the consensus is 32-bit off_t on 32-bit kernel and just
> live with all those *64 syscalls -- many not supported on palinux
> yet I notice.

Remember providing you use off_t you can just tell glibc to do all the work
for you and write with a 64bit off_t to userspace

Re: [parisc-linux] Include trouble

[John David Anglin]

> = Hmm.  Most 32 bit systems use "unsigned int" rather than "unsigned long".
> 
> I will be happy to change it back to unsigned int.  The only reason
> I used unsigned long is because it seems off_t wants to be, to a
> first approximation, the word length of the machine, and 'long' does
> that.

Agreed.

> = Using "unsigned long" might cause problems with packages like libio.
> 
> 
> = I know there is a problem if off_t is not the same as size_t.
> 
> What problem is that?  I'm working on a proposal for the palinux
> type sizes at the moment.

It is simply dumb coding that hasn't been fixed.  There are inconsistencies
between the interface declarations and implementations.  The old libio
is on the way out.

> One dilema is that off_t is supposed to
> be good for file offsets, which these days means it should be 64 bits.
> size_t refers to the sizes of objects which are expected to fit in
> RAM, so should be the word size of the machine.  So there's a conflict
> because one logic suggests 64-bit off_t and 32-bit size_t on 32-bit palinux,
> but your statement suggests they should be the same size.  Any ideas?

Only, because of poorly written legacy code.  I agree that off_t should
be 64 bits on 32 bit platforms today.

> However I'm leaning towards leaning with the older 32-bit off_t because
> we might not want to be the first ones to fix all the problems with
> making it 64 bits on a 32-bit machine.

Maybe it isn't that bad because I noticed at least one port used unsigned
long long for off_t.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Include trouble

[John David Anglin]

> Maybe it isn't that bad because I noticed at least one port used unsigned
> long long for off_t.

Take that back.  It was __kernel_loff_t.  Just go with

typedef unsigned int	__kernel_size_t;
typedef long            __kernel_off_t;
#ifdef __GNUC__
typedef long long	__kernel_loff_t;
#endif

for the 32 bit port.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Include trouble

[Alan Modra]

On Tue, 28 Nov 2000, John David Anglin wrote:

> Hmm.  Most 32 bit systems use "unsigned int" rather than "unsigned long".

There's some precedent for using "unsigned long", as that is what is used
on 32-bit hpux11 and osf gcc targets.

current sourceware CVS gcc/config/pa/:

$ grep SIZE_TYPE *
grep: CVS: Is a directory
pa-64.h:#undef SIZE_TYPE
pa-64.h:#define SIZE_TYPE "long unsigned int"
pa-hpux.h:#undef SIZE_TYPE
pa-hpux.h:#define SIZE_TYPE "unsigned int"
pa-hpux11.h:#undef SIZE_TYPE
pa-hpux11.h:#define SIZE_TYPE "long unsigned int"
pa-hpux7.h:#undef SIZE_TYPE
pa-hpux7.h:#define SIZE_TYPE "unsigned int"
pa-linux.h:#undef SIZE_TYPE
pa-linux.h:#define SIZE_TYPE "unsigned int"
pa-osf.h:#undef SIZE_TYPE
pa-osf.h:#define SIZE_TYPE "long unsigned int"
pa-pro-end.h:#undef SIZE_TYPE
pa-pro-end.h:#define SIZE_TYPE "unsigned int"
pa.h:#define SIZE_TYPE "unsigned int"

Some further grepping shows quite a number of other 32-bit gcc targets
using "unsigned long", but I didn't see any 32-bit linux targets in the
list.  Paul, If you change back to "unsigned int", please change
gcc/config/pa/pa-linux.h too.

Alan
-- 
Linuxcare.  Support for the Revolution.

[parisc-linux] Mouse driver for PS/2

[Thomas Marteau]

Hi all,

	We appreciate if someone can explain where we can find request_irq and
request_region in hp_psaux.c and also,
what are they doing?

Thanks,
ESIEE Team

Re: [parisc-linux] Mouse driver for PS/2

[Helge Deller]

On Tuesday 28 November 2000 16:07, Thomas Marteau wrote:
> Hi all,

Hi Thomas,

>
> 	We appreciate if someone can explain where we can find request_irq

#include <linux/sched.h> and /arch/parisc/kernel/irq.c
request_irq() binds the given interrupt-number to a function (if possible).

> and
> request_region 

#include <linux/ioport.h>
request_region only marks (and tests) an I/O-region as used by a driver and 
makes this information visible via /proc/iomem and /proc/ioports.

> in hp_psaux.c and also,
> what are they doing?
>
> Thanks,
> ESIEE Team

Re: [parisc-linux] Mouse driver for PS/2

[Thomas Marteau]

Hi all,

	We have a sample of code for the mouse driver. But, we would like to
know how the Puffin would like the implementation of the driver. Because
of drag & drop..., do you want two different interrupt functions or a
single that does a redirection. Also , we have seen that busmouse.c is
quite interesting for our driver. Do we make a copy and call it
hp_mouse.c?

Thanks for your answer,
ESIEE Team
For a better future with a mouse!

Re: [parisc-linux] Mouse driver for PS/2

[Helge Deller]

On Tuesday 28 November 2000 20:30, Thomas Marteau wrote:
> Hi all,

Hi Thomas,

>
> 	We have a sample of code for the mouse driver. But, we would like to
> know how the Puffin would like the implementation of the driver. Because
> of drag & drop..., do you want two different interrupt functions or a
> single that does a redirection. Also , we have seen that busmouse.c is
> quite interesting for our driver. Do we make a copy and call it
> hp_mouse.c?

I would propose, that you check in hp_mouse.c and use different interrupt 
functions for now. Changing it later shouldn't be too difficult.

Greetings,
	Helge.  

>
> Thanks for your answer,
> ESIEE Team
> For a better future with a mouse!

Re: [parisc-linux] Mouse driver for PS/2

[Grant Grundler]

Thomas Marteau wrote:
> Hi all,
> 
> 	We appreciate if someone can explain where we can find request_irq and
> request_region in hp_psaux.c and also, what are they doing?

include/linux/sched.h:extern int request_irq(unsigned int, ...)
(Implementation is in arch/parisc/kernel/irq.c)

The request_irq() "allocates" an IRQ line for use by the device - this
program the PIC (or APIC) on x86 platforms. request_irq() is also how
an interrupt handler is associated with a specific IRQ line. Since
PA Risc CPU's don't have IRQ lines going into them, IRQ's are virtualized
and don't always represent a physical IRQ line.

Under LASI, see gsc_alloc_irq(&gsc_irq) usage in drivers/gsc/lasi.c.
lasi_find_irq() helps associate the PS/2 interrupt handler with
the correct IRQ line which is internal to lasi.


include/linux/ioport.h:#define request_region(start,n,name) ...

request_region() will reserve a range of I/O port address from the
global I/O space. request_mem_region() does the same for MMIO.
Drivers that use inb/outb (as defined in include/asm-parisc/io.h)
must use request_region(). Drivers that use gsc_readb/gsc_writeb
(as defined in include/asm-parisc/gsc.h) must use request_mem_region().

Collisions are probably occuring where a driver originally used inb/outb
and those were redefined to use gsc_readb/writeb functions. But the
driver is still using request_region().


And it doesn't help that I may have broken some of the resource mgt
with some code I committed last night. It worked on my boxes (A180/C3K)
but broke on other folks. Paul Bame helped find/fix one bug but
I shouldn't be surprised if more bugs are still out there.
I will be fixing some known resource failure problems on A500.
Please post problems on other platforms to parisc-linux list as well.

hope this helps,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253