On Mon, May 14, 2001 at 09:14:26PM +, Petr Vandrovec wrote:
> > 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.
>
> ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as
On Mon, May 14, 2001 at 09:14:26PM +, Petr Vandrovec wrote:
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.
ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
Vassilii:
> I am trying to understand what's the cleanest coding that would allow
> 1) user code to just use uid/gid for interfacing the driver control
> structures
> 2) driver code to read/write the corresponding structure fields with minimum
> awareness of the actual difference between kernel
Chris,
thanks for your reply.
My case is exactly when copying has to be made, hence the awareness
of the user/kernel uid/gid "personalities".
I am trying to understand what's the cleanest coding that would allow
1) user code to just use uid/gid for interfacing the driver control
structures
2)
Vassilii:
__kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t
are NOT supposed to be different in kernel and user space.
They used to differ, and the junk in /include/linux/highuid.h is there to
handle all old programs which used the smaller (16-bit) uid_t.
Kernel code
On 14 May 01 at 15:00, Khachaturov, Vassilii wrote:
> 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.
ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
'long' type for
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
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
On 14 May 01 at 15:00, Khachaturov, Vassilii wrote:
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.
ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
'long' type for
Vassilii:
__kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t
are NOT supposed to be different in kernel and user space.
They used to differ, and the junk in /include/linux/highuid.h is there to
handle all old programs which used the smaller (16-bit) uid_t.
Kernel code
Chris,
thanks for your reply.
My case is exactly when copying has to be made, hence the awareness
of the user/kernel uid/gid personalities.
I am trying to understand what's the cleanest coding that would allow
1) user code to just use uid/gid for interfacing the driver control
structures
2)
Vassilii:
I am trying to understand what's the cleanest coding that would allow
1) user code to just use uid/gid for interfacing the driver control
structures
2) driver code to read/write the corresponding structure fields with minimum
awareness of the actual difference between kernel and
12 matches
Mail list logo
