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

[Michael Kerrisk <mtk-manpages@gmx.net>]

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
;-).

Cheers,

Michael

-- 
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
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.