lkml.org 
[lkml]   [2001]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectuid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t
Date
I had to communicate uid/gid from an application down 
to a driver, and discovered that uid and gid in user
space are different from those in kernel space.

I am porting both the driver and the app from platforms
where uid and gid in userland don't differ from their
counterparts down in the kernel.

What would be the appealing portable way (across all
Linux platforms with their different byteorders) to
declare a type for such user/kernel interface?

Right now I am using smth that I feel is ugly a bit,
to declare fields of a transparent type:
/* MY uid_t/gid_t - shared types for user and kernel space */
#if defined(LINUX) && defined (__KERNEL__)

#ifdef CONFIG_X86

# define my_uid_t(var_name,pad_name) \
__kernel_uid_t var_name; unsigned short pad_name
# define my_gid_t(var_name,pad_name) \
__kernel_gid_t var_name; unsigned short pad_name
#else /* other archs I need to support, with arch-specific alignment */
...
#endif

#else /* Not Linux kernel - uid/gid same in user/kernel space */
# define my_uid_t(var_name,pad_name) uid_t var_name
# define my_gid_t(var_name,pad_name) gid_t var_name
#endif

and also I need special functions to set/get the var+
padding in kernel to make sure that the padding is set
to 0/-1 according to the sign of the var, each time I get
smth from/send smth to the userland from the kernel.

Is there a known pattern for doing things like this?
Maybe some special macros just for gid/uid specifically? I am
just feeling that I try reinvent a wheel here...

Kind regards,
Vassilii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.043 / U:2.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site