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

From: Michael Kerrisk
Date: Mon Sep 24 2007 - 15:52:57 EST

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


#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)


#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



Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

Want to help with man page maintenance? Grab the latest tarball at
read the HOWTOHELP file and grep the source files for 'FIXME'.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at