On Sat, Sep 22, 2007 at 06:07:14PM +0200, Michael Kerrisk wrote:
On 9/22/07, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
In article <[EMAIL PROTECTED]> you wrote:
> 1. This design stretches the POSIX timers API in strange
> ways.
Maybe it is possible to reimplement the POSIX API in usermode
Davide Libenzi wrote:
On Sun, 23 Sep 2007, Davide Libenzi wrote:
On Sun, 23 Sep 2007, Michael Kerrisk wrote:
I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
in the definitions below. When I ran the the program below, my system
immediately froze. Can you try it on
On Sun, 23 Sep 2007, Davide Libenzi wrote:
> On Sun, 23 Sep 2007, Michael Kerrisk wrote:
>
> > I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> > in the definitions below. When I ran the the program below, my system
> > immediately froze. Can you try it on your syst
On Sun, 23 Sep 2007, Michael Kerrisk wrote:
> I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown
> in the definitions below. When I ran the the program below, my system
> immediately froze. Can you try it on your system please.
There's an hrtimer_init() missing in timer
Hi Davide,
Davide Libenzi wrote:
> On Sat, 22 Sep 2007, Michael Kerrisk wrote:
>
>> So I'm inclined to implement option (b), unless someone has strong
>> objections. Davide, could I persuade you to help?
>
> I guess I better do, otherwise you'll continue to stress me ;)
Thanks -- that was more
On Sat, 22 Sep 2007, Thomas Gleixner wrote:
> On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote:
> > On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> >
> > > So I'm inclined to implement option (b), unless someone has strong
> > > objections. Davide, could I persuade you to help?
> >
> > I g
On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote:
> On Sat, 22 Sep 2007, Michael Kerrisk wrote:
>
> > So I'm inclined to implement option (b), unless someone has strong
> > objections. Davide, could I persuade you to help?
>
> I guess I better do, otherwise you'll continue to stress me ;)
On Sat, 22 Sep 2007, Michael Kerrisk wrote:
> So I'm inclined to implement option (b), unless someone has strong
> objections. Davide, could I persuade you to help?
I guess I better do, otherwise you'll continue to stress me ;)
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int f
Michael,
On Sat, 2007-09-22 at 15:12 +0200, Michael Kerrisk wrote:
> Davide, Andrew, Linus, et al.
>
> At the start of this thread
> (http://thread.gmane.org/gmane.linux.kernel/581115 ), I proposed 4
> alternatives to Davide's original timerfd API. Based on the feedback in
> that thread (and one
On Sat, 2007-09-22 at 18:07 +0200, Michael Kerrisk wrote:
> Hello Bernd,
>
> Please don't trim the CC list when replying! I nearly did not see
> your reply, and others will have missed it also.
Yup.
> On 9/22/07, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]> you
Hello Bernd,
Please don't trim the CC list when replying! I nearly did not see
your reply, and others will have missed it also.
On 9/22/07, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > 1. This design stretches the POSIX timers API in strange
> >
In article <[EMAIL PROTECTED]> you wrote:
> 1. This design stretches the POSIX timers API in strange
> ways.
Maybe it is possible to reimplement the POSIX API in usermode using the
kernel's FD implementation? (and drop the posix support from kernel)
Gruss
Bernd
-
To unsubscribe from this lis
Davide, Andrew, Linus, et al.
At the start of this thread
(http://thread.gmane.org/gmane.linux.kernel/581115 ), I proposed 4
alternatives to Davide's original timerfd API. Based on the feedback in
that thread (and one or two earlier comments):
Let's dismiss option (a), since it is an unlovely mu
David Härdeman wrote:
> On Tue, September 18, 2007 13:30, Thomas Gleixner wrote:
timer_gettime(fd | POSIX_TIMER_FD, .);
>> If we use the most significant bit for POSIX_TIMER_FD, we should be
>> fine.
>
> I think alternative b) - three new syscalls, sounds better.
>
> The only neg
On Tue, 18 Sep 2007, Michael Kerrisk wrote:
> The four designs are:
>
> a) A multiplexing timerfd() system call.
> b) Creating three syscalls analogous to the POSIX timers API (i.e.,
>timerfd_create/timerfd_settime/timerfd_gettime).
> c) Creating a simplified timerfd() system call that is int
On Tue, September 18, 2007 13:30, Thomas Gleixner wrote:
>>> timer_gettime(fd | POSIX_TIMER_FD, .);
>
> If we use the most significant bit for POSIX_TIMER_FD, we should be
> fine.
I think alternative b) - three new syscalls, sounds better.
The only negatives so far are that it adds mo
On Tue, 2007-09-18 at 13:08 +0200, Michael Kerrisk wrote:
> > > it does make the API a little more clumsy.
> >
> > Hmm, we might do something like:
> >
> > timer_gettime(fd | POSIX_TIMER_FD, .);
> >
> > So the kernel looks up the fd in order to figure out the timer_id, which
> > needs to
Hi Thomas,
> Von: Thomas Gleixner <[EMAIL PROTECTED]>
> On Tue, 2007-09-18 at 11:30 +0200, Michael Kerrisk wrote:
> > > This way we have it nicely integrated into the posix timer code and keep
> > > the existing semantics of posix timers intact.
> > >
> > > We need to think about the open file de
On Tue, 2007-09-18 at 11:30 +0200, Michael Kerrisk wrote:
> > This way we have it nicely integrated into the posix timer code and keep
> > the existing semantics of posix timers intact.
> >
> > We need to think about the open file descriptor in the timer_delete()
> > case as well, but this should
Hi Thomas,
> On Tue, 2007-09-18 at 09:30 +0200, Michael Kerrisk wrote:
> > > a) Add an argument (a multiplexing timerfd() system call)
> > Disadvantage:
> > Jon Corbet pointed out
> > (http://thread.gmane.org/gmane.linux.kernel/559193/focus=570709 )
> > that this interface was starting to look
On Tue, 2007-09-18 at 11:01 +0200, Michael Kerrisk wrote:
> > With solution c) you have to keep two
> > references to the same timer around and use one of them depending on what
> > you want to do with the timer.
>
> Yes. (And the same for option (d).)
>
> > Also, if the timerfd is close():d, do
Michael,
On Tue, 2007-09-18 at 09:30 +0200, Michael Kerrisk wrote:
> > a) Add an argument (a multiplexing timerfd() system call)
> Disadvantage:
> Jon Corbet pointed out
> (http://thread.gmane.org/gmane.linux.kernel/559193/focus=570709 )
> that this interface was starting to look like a multip
Hello David,
Thanks for taking a look at this.
> On Tue, September 18, 2007 09:30, Michael Kerrisk wrote:
> > > b) Create a timerfd interface analogous to POSIX timers
> >
> > Create an interface analogous to POSIX timers:
> > fd = timerfd_create(clockid, flags);
> > timerfd_settime(fd, flags
On Tue, September 18, 2007 09:30, Michael Kerrisk wrote:
> > b) Create a timerfd interface analogous to POSIX timers
>
> Create an interface analogous to POSIX timers:
> fd = timerfd_create(clockid, flags);
> timerfd_settime(fd, flags, newtimervalue, &time_to_next_expire);
> timerfd_gettime(fd,
[Resend, because I got one email address wrong in the earlier send]
After my earlier mail (full thread here:
http://thread.gmane.org/gmane.linux.kernel/574430/focus=579368 )
it seems that some people agree we should give a bit more
thought to how a final timerfd interface should look.
Davide's or
25 matches
Mail list logo
