bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libparted/linux.c include broken copy of linux/fs.h


From: Yury V. Umanets
Subject: Re: libparted/linux.c include broken copy of linux/fs.h
Date: Mon, 10 Nov 2003 16:38:12 +0300

On Mon, 2003-11-10 at 15:25, Sven Luther wrote:
> On Mon, Nov 10, 2003 at 03:22:34PM +0300, Yury V. Umanets wrote:
> > On Mon, 2003-11-10 at 13:33, Sven Luther wrote:
> > > Hello,
> > > 
> > > I have been battling since a week or so with a problem which appeared
> > > now that debian glibc include a copy of the linux 2.6.0-test9 includes.
> > > 
> > > The linux.c file in the libparted directory contains its own copy of the
> > > some of the linux/fs.h headers, which breaks now that the linux/fs.h
> > > headers have changed some (to fix a bug on 32bit userland on 64bit
> > > kernels i think).
> > > 
> > > The incriminated defines are :
> > > 
> > > #define BLKGETLASTSECT  _IO(0x12,108) /* get last sector of block device 
> > > */
> > > #define BLKSETLASTSECT  _IO(0x12,109) /* set last sector of block device 
> > > */
> > 
> > > #define BLKGETSIZE64 _IOR(0x12,114,sizeof(uint64_t))      /* return 
> > > device size in bytes (u64 *arg) */
> > > 
> > I guess, that this define should look like the following:
> > #define BLKGETSIZE64 _IOR(0x12,114,uint64_t)
> 
> Well, maybe, but as said, the kernel still says size_t, despite this
> having be remarked on lkml since early september.
I have meant, that there should be just type, not sizeof(type). 
> 
> > We have recently fased with this problem in reiser4progs. One of testers
> > have pointed us to this.
> 
> And, do you know of any reason why choosing uint64_t over size_t, when
> this has not yet been changed in the kernel ?

> 
> Friendly,
> 
> Sven Luther
-- 
umka





reply via email to

[Prev in Thread] Current Thread [Next in Thread]