Re: [patch 2/3] new timerfd API - wire the new timerfd API to the x86 family

[Davide Libenzi <davidel@xmailserver.org>]

On Mon, 24 Sep 2007, Michael Kerrisk wrote:

> Hi Davide,
> 
> Davide Libenzi wrote:
> > On Mon, 24 Sep 2007, Michael Kerrisk wrote:
> >> Is it perhaps not better to group the three syscalls contiguously with
> >> respect to syscall numbers?  The old timerfd slot can be re-used for some
> >> other syscall later.
> > 
> > There's no problem if they're not contiguous. 
> 
> I realise there is no problem, in a technical sense.  But it strikes me as
> more aesthetic to make related syscalls numerically contiguous.  Thus, we
> see such as the following in the kernel source
> 
> #define __NR_epoll_create       254
> #define __NR_epoll_ctl          255
> #define __NR_epoll_wait         256
> 
> and
> 
> #define __NR_timer_create       259
> #define __NR_timer_settime      (__NR_timer_create+1)
> #define __NR_timer_gettime      (__NR_timer_create+2)
> #define __NR_timer_getoverrun   (__NR_timer_create+3)
> #define __NR_timer_delete       (__NR_timer_create+4)
> 
> and
> 
> #define __NR_inotify_init       291
> #define __NR_inotify_add_watch  292
> #define __NR_inotify_rm_watch   293
> 
> > Holes, unless filled 
> > immediately, need to be remembered to be filled.
> 
> Well, in the past it seems they do get filled soon enough though.  There's
> fair odds that you'll be the one to fill it with the next syscall you write
> ;-).

You have to talk to arch mantainers. I do not care. I simply provided the 
x86 hooks because I tested on x86.



- Davide


-
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/