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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 24 Sep 2007 12:56:27 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Michael Kerrisk <mtk-manpages@....net>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 2/3] new timerfd API - wire the new timerfd API to the
 x86 family

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/