Hello.
Please _NEVER_ drop Cc: list, since not everyone can be subscribed to
linux-kernel@, fortunately I'm not for example.
On Wed, Dec 13, 2006 at 06:51:47PM +0530, Tushar Adeshara ([EMAIL PROTECTED])
wrote:
> I think these four lines are not required. Irrespective of return
> value of
On 11/23/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Wed, Nov 22, 2006 at 01:44:16PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
+static int posix_kevent_init_timer(struct k_itimer *tmr, int fd)
+{
+ struct ukevent uk;
+ struct file *file;
+ struct kevent_user
Hello.
Please _NEVER_ drop Cc: list, since not everyone can be subscribed to
linux-kernel@, fortunately I'm not for example.
On Wed, Dec 13, 2006 at 06:51:47PM +0530, Tushar Adeshara ([EMAIL PROTECTED])
wrote:
I think these four lines are not required. Irrespective of return
value of
On Mon, Dec 11, 2006 at 05:36:44PM -0800, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 22:22:36 +0300
>
> > And, btw, last time I checked, aligned_u64 was not exported to
> > userspace.
>
> It is in linux/types.h and not protected
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 28 Nov 2006 22:22:36 +0300
> And, btw, last time I checked, aligned_u64 was not exported to
> userspace.
It is in linux/types.h and not protected by __KERNEL__ ifdefs.
Perhaps you mean something else?
-
To unsubscribe from this list: send the
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 28 Nov 2006 22:22:36 +0300
And, btw, last time I checked, aligned_u64 was not exported to
userspace.
It is in linux/types.h and not protected by __KERNEL__ ifdefs.
Perhaps you mean something else?
-
To unsubscribe from this list: send the
On Mon, Dec 11, 2006 at 05:36:44PM -0800, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 28 Nov 2006 22:22:36 +0300
And, btw, last time I checked, aligned_u64 was not exported to
userspace.
It is in linux/types.h and not protected by
On Tue, Nov 28, 2006 at 11:13:00AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 12:16:02 +0300
>
> > Although ukevent has pointer embedded, it is unioned with u64, so there
> > should be no problems until 128 bit arch
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 28 Nov 2006 12:16:02 +0300
> Although ukevent has pointer embedded, it is unioned with u64, so there
> should be no problems until 128 bit arch appeared, which likely will not
> happen soon. There is also unused in kevent posix timers patch
>
On Mon, Nov 27, 2006 at 10:20:50AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> sigev_value is a union and the largest element is a pointer. So,
> transporting the pointer value is sufficient and it should be passed up
> to the user in the ptr member of struct ukevent.
That is where
On Mon, Nov 27, 2006 at 10:49:55AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Mon, 27 Nov 2006 10:36:06 -0800
>
> > David Miller wrote:
> > > Now we'll have to have a compat layer for 32-bit/64-bit environments
> > > thanks to POSIX timers,
On Mon, Nov 27, 2006 at 10:49:55AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
From: Ulrich Drepper [EMAIL PROTECTED]
Date: Mon, 27 Nov 2006 10:36:06 -0800
David Miller wrote:
Now we'll have to have a compat layer for 32-bit/64-bit environments
thanks to POSIX timers, which is
On Mon, Nov 27, 2006 at 10:20:50AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
sigev_value is a union and the largest element is a pointer. So,
transporting the pointer value is sufficient and it should be passed up
to the user in the ptr member of struct ukevent.
That is where I've
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 28 Nov 2006 12:16:02 +0300
Although ukevent has pointer embedded, it is unioned with u64, so there
should be no problems until 128 bit arch appeared, which likely will not
happen soon. There is also unused in kevent posix timers patch
'u32
On Tue, Nov 28, 2006 at 11:13:00AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Tue, 28 Nov 2006 12:16:02 +0300
Although ukevent has pointer embedded, it is unioned with u64, so there
should be no problems until 128 bit arch appeared, which
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: Mon, 27 Nov 2006 10:36:06 -0800
> David Miller wrote:
> > Now we'll have to have a compat layer for 32-bit/64-bit environments
> > thanks to POSIX timers, which is rediculious.
>
> We already have compat_sys_timer_create. It should be sufficient
David Miller wrote:
Now we'll have to have a compat layer for 32-bit/64-bit environments
thanks to POSIX timers, which is rediculious.
We already have compat_sys_timer_create. It should be sufficient just
to add the conversion (if anything new is needed) there. The pointer
value can be
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: Mon, 27 Nov 2006 10:20:50 -0800
> Evgeniy Polyakov wrote:
> >> We need to pass the data in the sigev_value meember of the struct
> >> sigevent structure passed to timer_create to the caller. I don't see it
> >> being done here nor when the timer
Evgeniy Polyakov wrote:
We need to pass the data in the sigev_value meember of the struct
sigevent structure passed to timer_create to the caller. I don't see it
being done here nor when the timer is created. Do I miss something?
The sigev_value value should be stored in the user/ptr member
Evgeniy Polyakov wrote:
We need to pass the data in the sigev_value meember of the struct
sigevent structure passed to timer_create to the caller. I don't see it
being done here nor when the timer is created. Do I miss something?
The sigev_value value should be stored in the user/ptr member
From: Ulrich Drepper [EMAIL PROTECTED]
Date: Mon, 27 Nov 2006 10:20:50 -0800
Evgeniy Polyakov wrote:
We need to pass the data in the sigev_value meember of the struct
sigevent structure passed to timer_create to the caller. I don't see it
being done here nor when the timer is created.
David Miller wrote:
Now we'll have to have a compat layer for 32-bit/64-bit environments
thanks to POSIX timers, which is rediculious.
We already have compat_sys_timer_create. It should be sufficient just
to add the conversion (if anything new is needed) there. The pointer
value can be
From: Ulrich Drepper [EMAIL PROTECTED]
Date: Mon, 27 Nov 2006 10:36:06 -0800
David Miller wrote:
Now we'll have to have a compat layer for 32-bit/64-bit environments
thanks to POSIX timers, which is rediculious.
We already have compat_sys_timer_create. It should be sufficient just
to
23 matches
Mail list logo
