FYI
/usr/include/bits/types.h
/* Fixed-size types, underlying types depend on word size and compiler. */
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
#if __WORDSIZE == 64
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
#elif defined __GLIBC_HAVE_LONG_LONG
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
#endif
#if __WORDSIZE == 32
# define __SQUAD_TYPE __quad_t
# define __UQUAD_TYPE __u_quad_t
# define __SWORD_TYPE int
# define __UWORD_TYPE unsigned int
# define __SLONG32_TYPE long int
# define __ULONG32_TYPE unsigned long int
# define __S64_TYPE __quad_t
# define __U64_TYPE __u_quad_t
/* We want __extension__ before typedef's that use nonstandard base types
such as `long long' in C89 mode. */
# define __STD_TYPE __extension__ typedef
#elif __WORDSIZE == 64
# define __SQUAD_TYPE long int
# define __UQUAD_TYPE unsigned long int
# define __SWORD_TYPE long int
# define __UWORD_TYPE unsigned long int
# define __SLONG32_TYPE int
2009/7/13 SandeepKsinha <sandeepksinha@xxxxxxxxx>:
>
> Regards,
> Sandeep.
>
>
>
>
>
> Hi Pie,
>
> “To learn is to change. Education is a process that changes the learner.”
>
>
> On Mon, Jul 13, 2009 at 11:31 AM, Pei Lin <telent997@xxxxxxxxx> wrote:
>>
>> Is it different?
>
> Yes. they are.
>
>>
>> let us see the typedef about this two.
>> user space: unsigned long int
>> kernel space :
>> typedef __u32 __kernel_dev_t;
>> typedef __kernel_dev_t dev_t;
>>
>> "long int " in 64bit cpu should be 8 bytes
>
> [12:02:21 sinhas]$ ./a.out
>
> unsigned long int size = 4
> dev_t size = 8
> unsigned long size = 4
> int size = 4[~]
> [12:02:24 sinhas]$
>
>
> So, here long is 32bits on 32 bit and 64 bits on 64 bit.
>
> Where did you get the definition of dev_t to be unsigned long int?
>
> Its defined as unsigned long long
> dev_t ->__dev_t -> __STD_TYPE __DEV_T_TYPE __dev_t; -> # define
> __STD_TYPE __extension__ typedef ->
>
> __extension__ typedef signed long long int __int64_t;
> __extension__ typedef unsigned long long int __uint64_t;
>
>
>
>
>>
>> So i think in 32 bit cpu they are same,and if your kernel compile for
>> 32 and user space configuration for 64.....
>> Is it the problem ?
>
> Explained above.
>
>>
>> BRs,
>>
>> Lin
>>
>> 2009/7/13 SandeepKsinha <sandeepksinha@xxxxxxxxx>:
>> > Hi Greg,
>> >
>> > find my reply inline.
>> >
>> > On Sun, Jul 12, 2009 at 11:44 PM, Greg KH <greg@xxxxxxxxx> wrote:
>> >>
>> >> On Sun, Jul 12, 2009 at 10:16:17PM +0530, SandeepKsinha wrote:
>> >> > Hi,
>> >> > to my surprise,
>> >> > the sizeof dev_t differs in userspace and kernel.
>> >> > Its 8 bytes in userspace and 4bytes in kernel.
>> >> >
>> >> > I am working on a driver, where I include the headers in both user
>> >> > and
>> >> > kernel space.
>> >> > And I get wrong values due to the difference in sizes.
>> >> >
>> >> > How do I handle such a situation ?
>> >>
>> >> Why would you be passing a dev_t from user to kernel space as a binary
>> >> value?
>> >
>> > I am not passing a dev_t as a binary from userspace to kernel space.
>> > Its a part of the structure.
>> >
>> > E.g
>> >
>> > struct device_info {
>> >
>> > dev_t dev_num;
>> > ...
>> > ....
>> > }
>> >
>> >
>> >>
>> >> Why do you want to pass such a value across the boundry in the first
>> >> place?
>> >
>> > This is pretty much for a custom driver, where I perform the following.
>> > 1. Parse the information in user space from a XML file
>> > 2. Do a stat on the device,
>> > 3. extract the device number
>> > 4. Fill in the structure
>> > 5. Pass it to the kernel driver using ioctl.
>> >
>> > Reference: OHSM : http://code.google.com/p/fscops/
>> >
>> >>
>> >> Could you describe what the problem is you are trying to sove by doing
>> >> this?
>> >
>> > Its just a part of my implementation. And I wanted to keep this uniform
>> > across the system.
>> > But having such discrepancies really disappointed me.
>> >
>> > But I still don't understand the philosophy behind having different
>> > sizes
>> > for dev_t in user and kernel space.
>> > And most importantly, its not documented and it eventually leads to
>> > silent
>> > corruption. Which is real difficult to trace in complex systems.
>> >
>> >
>> >>
>> >> thanks,
>> >>
>> >> greg k-h
>> >
>> > Regards,
>> > Sandeep.
>> >
>> >
>> > “To learn is to change. Education is a process that changes the
>> > learner.”
>> >
>
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
