Hi Davide,
>> This function is *not at all* equivalent to the "get"
>> functionality of the previous APIs. The "get" functionality
>> of POSIX timers (for example) returns a structure that contains
>> the timer interval and the *time until the next expiration of
>> the timer* (not the initial tim
On Thu, 6 Sep 2007, Michael Kerrisk wrote:
> You are asserting this in the face of two previous APIs designed
> by people who (at least in the case of POSIX timers) probably
> thoroughly examined and discussed existing APIs and practice.
You really think that. Uhmm, ok.
> This function is *n
Hi Davide,
> > > > > > > > As I think about this more, I see more problems with
> > > > > > > > your argument. timerfd needs the ability to get and
> > > > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > > > Consider a library that creates a timerfd file descriptor
> > >
On Thu, 6 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > > > > > > As I think about this more, I see more problems with
> > > > > > > your argument. timerfd needs the ability to get and
> > > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > > Consider a library that
Hi Davide,
> > > > > > As I think about this more, I see more problems with
> > > > > > your argument. timerfd needs the ability to get and
> > > > > > get-while-setting just as much as the earlier APIs.
> > > > > > Consider a library that creates a timerfd file descriptor that
> > > > > > is ha
On Wed, 5 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > > > > As I think about this more, I see more problems with
> > > > > your argument. timerfd needs the ability to get and
> > > > > get-while-setting just as much as the earlier APIs.
> > > > > Consider a library that creates a timerf
Hi Davide,
> > > > As I think about this more, I see more problems with
> > > > your argument. timerfd needs the ability to get and
> > > > get-while-setting just as much as the earlier APIs.
> > > > Consider a library that creates a timerfd file descriptor that
> > > > is handed off to an appli
On Wed, 5 Sep 2007, Michael Kerrisk wrote:
> Davide,
A Michael!
> > > As I think about this more, I see more problems with
> > > your argument. timerfd needs the ability to get and
> > > get-while-setting just as much as the earlier APIs.
> > > Consider a library that creates a timerfd file d
On Tuesday 04 September 2007 16:25, Davide Libenzi wrote:
> On Tue, 4 Sep 2007, Andrew Morton wrote:
>
> > > On Tue, 04 Sep 2007 10:03:56 +0200 Michael Kerrisk <[EMAIL PROTECTED]>
> > > wrote:
> > > Davide,
> > >
> > > >> Davide -- ping! Can you please offer your comments about this change,
>
> On Wed, 05 Sep 2007 02:08:31 +0200 "Michael Kerrisk" <[EMAIL PROTECTED]>
> wrote:
> Davide,
>
> > > As I think about this more, I see more problems with
> > > your argument. timerfd needs the ability to get and
> > > get-while-setting just as much as the earlier APIs.
> > > Consider a library
Davide,
> > As I think about this more, I see more problems with
> > your argument. timerfd needs the ability to get and
> > get-while-setting just as much as the earlier APIs.
> > Consider a library that creates a timerfd file descriptor that
> > is handed off to an application: that library ma
On Tue, 4 Sep 2007, Michael Kerrisk wrote:
> > Useless like it'd be a motorcycle w/out a cup-holder :)
> > Seriously, the ability to get the previous values from "something" could
> > have a meaning if this something is a shared global resource (like
> > signals
> > for example). In the timerfd
On Tue, 4 Sep 2007, Michael Kerrisk wrote:
> Hi Davide,
>
> > >
> > >
> > > I'd have thought that the existing stuff would be near-useless without
> > > the capabilities which you describe?
> >
> > Useless like it'd be a motorcycle w/out a cup-holder :)
> > Seriously, the ability to get the pr
> > > The ABI change doesn't really matter, since timerfd() was broken in
> > > 2.6.22 anyway.
> > >
> > > Both previous APIs provided the features I have described provide:
> > >
> > > * the ability to fetch the old timer value when applying
> > > a new setting
> > >
> > > * the ability to no
Hi Davide,
> >
> >
> > I'd have thought that the existing stuff would be near-useless without
> > the capabilities which you describe?
>
> Useless like it'd be a motorcycle w/out a cup-holder :)
> Seriously, the ability to get the previous values from "something" could
> have a meaning if this
On Tue, 4 Sep 2007, Andrew Morton wrote:
> > On Tue, 04 Sep 2007 10:03:56 +0200 Michael Kerrisk <[EMAIL PROTECTED]>
> > wrote:
> > Davide,
> >
> > >> Davide -- ping! Can you please offer your comments about this change,
> > >> and
> > >> also thoughts on Jon's and my comments about a more radi
[...]
> > Neither of the proposed APIs (either my multiplexed version of
> > timerfd()
> > or Jon's/my idea of using three system calls (like POSIX timers), or
> > the notion of timerfd() integrated with POSIX timers) is more
> > complicated than the existing POSIX timers API.
> >
> > The ABI cha
> On Tue, 04 Sep 2007 10:03:56 +0200 Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> Davide,
>
> >> Davide -- ping! Can you please offer your comments about this change, and
> >> also thoughts on Jon's and my comments about a more radical API change
> >> later in this thread.
> >
> > IMO the compl
Davide,
>> Davide -- ping! Can you please offer your comments about this change, and
>> also thoughts on Jon's and my comments about a more radical API change
>> later in this thread.
>
> IMO the complexity of the resulting API (and resulting patch), and the ABI
> change, is not justified by t
On Sat, 25 Aug 2007, Michael Kerrisk wrote:
> Davide -- ping! Can you please offer your comments about this change, and
> also thoughts on Jon's and my comments about a more radical API change
> later in this thread.
IMO the complexity of the resulting API (and resulting patch), and the ABI
ch
[resend, since LKML didn't like last send.]
Randy,
Thanks for the input. I will try to send a revised patch after I get back
from holiday. Some comments below.
Davide -- ping! Can you please offer your comments about this change, and
also thoughts on Jon's and my comments about a more radical
Sorry for the late commentary...as I looked this over, one thing popped
into my mind
> b) Make the 'clockid' immutable: it can only be set
>if 'ufd' is -1 -- that is, on the timerfd() call that
>first creates a timer.
timerfd() is looking increasingly like a multiplexor system call in
On Thu, 09 Aug 2007 23:11:45 +0200 Michael Kerrisk wrote:
> Andrew,
>
> Here's my first shot at changing the timerfd() interface; patch
> is against 2.6.23-rc1-mm2.
>
> I think I got to the bottom of understanding the timer code in
> the end, but I may still have missed some things...
>
> This
23 matches
Mail list logo
