Skip to contentSkip to conversation

Minor header bug? MIPS (32-bit) nlink_t sign

DISCUSSION Jamie Lokier 4 participants 5 messages Jan 18, 2003 – Jan 21, 2003

lore
Share & tools
lore

Jamie Lokier

author
#0 lore raw

Linux/MIPS32 is unusual in that its type of nlink_t is signed. In the header <asm-mips64/posix_types.h>, the 32-bit compatibility type for nlink_t is defined as unsigned. Perhaps this is because the MIPS 64-bit nlink_t is always unsigned.

Which header is correct - and which should be changed for consistency - <asm-mips/posix_types.h> or <asm-mips64/posix_types.h>?

Stephen, I guess you have already figured this out with your recent 32-bit compatibility cleanup?

cheers,
-- Jamie

#1 lore raw

Hi Jamie,

Quoted 3 lines · On Sat, 18 Jan 2003 03:34:35 +0000 Jamie Lokier <[email protected]> wrote:

Stephen, I guess you have already figured this out with your recent 32-bit compatibility cleanup?

I mainly did direct substitutions, but will have a look shortly and see what I think.

I assume we are being compatable with Irix? Ralf?

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#2 lore raw
Quoted 9 lines · Stephen Rothwell
Quoted 3 lines · On Sat, 18 Jan 2003 03:34:35 +0000 Jamie Lokier <[email protected]> wrote:

Stephen, I guess you have already figured this out with your recent 32-bit compatibility cleanup?

I mainly did direct substitutions, but will have a look shortly and see what I think.

I assume we are being compatable with Irix? Ralf?

nlink_t is a signed short on sparc32 as well, and yes this is to be compatible with SunOS

#3 lore raw
In reply to Stephen Rothwell
Quoted 7 lines · Stephen Rothwell
Quoted 2 lines

Stephen, I guess you have already figured this out with your recent 32-bit compatibility cleanup?

I mainly did direct substitutions, but will have a look shortly and see what I think.

I assume we are being compatable with Irix? Ralf?

Dunno where the signed int for nlink_t did come from. The original idea was to avoid pointless creativity and choose data types to match IRIX rsp. the MIPS psABI. As using a signed type didn't create any visible problems so far this never got noticed until Jamie Lokier mailed me last week. I now changed the definition to unsigned long for the 32-bit kernel and unsigned int for the 64-bit kernel.

Ralf

author
#4 lore raw
Quoted 5 lines · Ralf Baechle
Quoted 1 line

I assume we are being compatable with Irix? Ralf?

Dunno where the signed int for nlink_t did come from. The original idea was to avoid pointless creativity and choose data types to match IRIX rsp. the MIPS psABI.

(I've been going through all the <asm-*/*.h> API files, and there is a lot of duplication, with very small variations. It was with a view to getting rid of some of the duplication, and making it easy to see what the _real_ differences are).

MIPS and Sparc are the only architectures that decided to be really different to all the other Linux archs).

Anyway, I spotted another MIPS suggestion:

asm-mips/siginfo.h:

The comments explain that siginfo_t is IRIX compatible with extensions. In fact it is not IRIX compatible, now that siginfo_t._sigchld has an additional _uid field in the middle of it. So it's compatible for _some_ uses only.

It's obvious that the code author knew of this change (because _irix_sigchld is there to document it), but didn't change the comment.

Suggestion:

That comment should be removed or changed as siginfo_t is not IRIX compatible, at least in this part. And maybe _irix_sigchld should be removed, along with the comment.

cheers,
-- Jamie