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

Michael Kerrisk
2007-09-24T19:52:47Z

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'.