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
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 timer string, as
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
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:
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 *not
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
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
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
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
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
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 that creates a
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,
and
also
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 descriptor
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 application: that
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 timerfd file descriptor
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 application:
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 creates a timerfd file
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
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
> > > 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
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
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
[...]
> > 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
> 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
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
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 the added
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 complexity of the
[...]
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 change doesn't
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 radical API change
Hi Davide,
wakes up
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
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 non-destructively fetch the
On Tue, 4 Sep 2007, Michael Kerrisk wrote:
Hi Davide,
wakes up
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
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 case this
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 may want
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
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
[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
[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
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
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
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 is my
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 is my first kernel patch of any substance. Perhaps Randy
or Christoph can
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 is my first kernel patch of any substance. Perhaps Randy
or Christoph can
47 matches
Mail list logo
