[PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[Peter Chubb]

(2.5.21)  The third argument to BLKGETSIZE64 is declared as u64 in
include/linux/fs.h

I think it should be uint64_t to allow glibc to copy and mangle the file into
its header tree. 


===== include/linux/fs.h 1.112 vs edited =====
--- 1.112/include/linux/fs.h    Wed Jun 12 10:16:52 2002
+++ edited/include/linux/fs.h   Wed Jun 12 14:30:36 2002
@@ -196,7 +196,7 @@
 /* A jump here: 108-111 have been used for various private purposes. */
 #define BLKBSZGET  _IOR(0x12,112,sizeof(int))
 #define BLKBSZSET  _IOW(0x12,113,sizeof(int))
-#define BLKGETSIZE64 _IOR(0x12,114,sizeof(u64))        /* return device size in b
ytes (u64 *arg) */
+#define BLKGETSIZE64 _IOR(0x12,114,sizeof(uint64_t))   /* return device size in b
ytes (u64 *arg) */
 
 #define BMAP_IOCTL 1           /* obsolete - kept for compatibility */
 #define FIBMAP    _IO(0x00,1)  /* bmap access */

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[Rusty Russell]

In message <15622.54728.469214.307901@wombat.chubb.wattle.id.au> you write:
> 
> (2.5.21)  The third argument to BLKGETSIZE64 is declared as u64 in
> include/linux/fs.h
...
> -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(u64))        /* 
> +#define BLKGETSIZE64 _IOR(0x12,114,sizeof(uint64_t))   /* 

This is a wider question: uint64_t and int64_t (et. al) are ISO C
<stdint.h> requirements.  Whether we should begin migration in 2.5, or
leave them alone is a Linus question.

> I think it should be uint64_t to allow glibc to copy and mangle the file into
> its header tree. 

I don't think that's really an issue, is it?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[Peter Chubb]

>>>>> "Rusty" == Rusty Russell <rusty@rustcorp.com.au> writes:


>> I think it should be uint64_t to allow glibc to copy and mangle the
>> file into its header tree.

Rusty> I don't think that's really an issue, is it? 

This issue is that when I try to use the BLKGETSZ64 ioctl from a user space
program, the version of linux/fs.h shipped with glibc-2.2.5 contains a
u64 type.  u64 is kernel-only, the correct type to be shared between
user and kernel space is either uint64_t (mandated by C9X) or the
__u64 type from asm/types.h.  Either way, u64 is wrong.

You could argue that this is a glibc bug.  But the way that glibc
generates the include/linux headers is just to copy them from some
kernel tree or other, with a little mangling on the side.

--
Peter C					    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[Andreas Schwab]

Peter Chubb <peter@chubb.wattle.id.au> writes:

|> You could argue that this is a glibc bug.  But the way that glibc
|> generates the include/linux headers is just to copy them from some
|> kernel tree or other, with a little mangling on the side.

Glibc does not do anything with the kernel headers besides using some of
them.  Especially it does not generate any of them.  The fact that the
distributions usually pack the kernel headers together with the glibc
headers does not mean that the kernel headers belong to glibc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[David Woodhouse]

peter@chubb.wattle.id.au said:
> This issue is that when I try to use the BLKGETSZ64 ioctl from a user
> space program, the version of linux/fs.h shipped with glibc-2.2.5
> contains a u64 type. 

>  You could argue that this is a glibc bug.

I do indeed. I further argue that it has no business being discussed on the 
kernel mailing list, just because the kernel happens to have a header with 
a similar name.

> But the way that glibc generates the include/linux headers is just 
> to copy them from some kernel tree or other, with a little mangling
> on the side.

This errant behaviour would appear to be the cause of the bug you've
observed. Glibc should be providing its own header files.

--
dwmw2

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[Peter Chubb]

>>>>> "David" == David Woodhouse <dwmw2@infradead.org> writes:

David> peter@chubb.wattle.id.au said:
>> This issue is that when I try to use the BLKGETSZ64 ioctl from a
>> user space program, the version of linux/fs.h shipped with
>> glibc-2.2.5 contains a u64 type.

>> You could argue that this is a glibc bug.

David> I do indeed. I further argue that it has no business being
David> discussed on the kernel mailing list, just because the kernel
David> happens to have a header with a similar name.

The header in question *defines* the kernel to userspace interface.
As such it is a kernel issue.  Any interface exposed to userspace must
use types that are common to userspace and the kernel.  u64 is kernel
only, therefore has no business being used in an ioctl declaration.

--
Peter C					    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: [PATCH, TRIVIAL] Fix argument of BLKGETSIZE64

[David Woodhouse]

peter@chubb.wattle.id.au said:
>  The header in question *defines* the kernel to userspace interface.
> As such it is a kernel issue.  Any interface exposed to userspace must
> use types that are common to userspace and the kernel.  u64 is kernel
> only, therefore has no business being used in an ioctl declaration. 

Consider it documentation. Implement it. Don't include it.

--
dwmw2