On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > UNIX has pid's for "process" handles, and "file descriptors" for just
> > about everything else.
>
> And I imagine that somebody will come up with way of getting a fd for a
> process sooner or later.
Well, /proc// is about as close as you
On Sat, 10 Mar 2007, Nicholas Miell wrote:
UNIX has pid's for process handles, and file descriptors for just
about everything else.
And I imagine that somebody will come up with way of getting a fd for a
process sooner or later.
Well, /proc/pid/ is about as close as you get. And
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Ah, I see. You're just interested in fds as a generic handle concept,
> > and not a more Plan 9 type thing.
>
> Indeed. It's a "handle".
>
> UNIX has pid's for "process" handles, and
On Sat, 10 Mar 2007, Linus Torvalds wrote:
> > Actually, the only place where I can find the itimerspec usefull, is
> > indeed with TFD_TIMER_SEQ. In cases where you want you clock starting at a
> > given time (it_value) *and* with the given frequency (it_interval).
>
> .. and this is where
On Sat, 10 Mar 2007, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Linus Torvalds wrote:
>
> > (That said, using "struct itimerspec" might be a good idea. That would
> > also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically
> > has both "base" and "incremental" parts).
>
On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> Ah, I see. You're just interested in fds as a generic handle concept,
> and not a more Plan 9 type thing.
Indeed. It's a "handle".
UNIX has pid's for "process" handles, and "file descriptors" for just
about everything else.
> If that's the
On Sat, 10 Mar 2007, Linus Torvalds wrote:
> (That said, using "struct itimerspec" might be a good idea. That would
> also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically
> has both "base" and "incremental" parts).
But TFD_TIMER_SEQ is a simple auto-rearm case of
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > If that's the goal, somebody should start thinking about reducing the
> > contents of struct file to the bare minimum (i.e. not much more than a
> > file_operations pointer).
>
> That's
On Sat, 10 Mar 2007, Nicholas Miell wrote:
> If that's the goal, somebody should start thinking about reducing the
> contents of struct file to the bare minimum (i.e. not much more than a
> file_operations pointer).
That's already pretty smal, and the single inode (and maybe dentry) will
make
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> > >
> > > I'd actually much rather do POSIX timers the other way around: associate
> > > a
> > > generic notification mechanism with the file descriptor, and then
> > > implement
On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > I'd actually much rather do POSIX timers the other way around: associate a
> > generic notification mechanism with the file descriptor, and then
> > implement posix_timer_create() on top of timerfd. Now THAT sounds like a
> > clean unix-like
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > Care to elaborate on why they're a horrible crock?
>
> It's a *classic* case of an interface that tries to do everything under
> the sun.
>
> Here's a clue: look at any system call
On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> Care to elaborate on why they're a horrible crock?
It's a *classic* case of an interface that tries to do everything under
the sun.
Here's a clue: look at any system call that takes a union as part of its
arguments. Count them. I think we have
On Sat, 10 Mar 2007, Nicholas Miell wrote:
> I never complained about one timer per fd (although, now that you
> mention it, that would get a bit excessive if you have thousands of
> outstanding timers).
Right, of course.
> > The real-time and monotonic selection can be added.
>
> IOW, the
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
>
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > That's what the sigevent structure is for -- to describe how events
> > should be signaled to userspace, whether by signal delivery, thread
> > creation, or queuing to event completion
On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> That's what the sigevent structure is for -- to describe how events
> should be signaled to userspace, whether by signal delivery, thread
> creation, or queuing to event completion ports. If if you think
> extending it would be bad, I can show you
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
> On Sat, 10 Mar 2007, Nicholas Miell wrote:
>
> > Try reading the timer_create man page.
> >
> > In short, you're limited to a single clock, so you can't set timers
> > based on wall-clock time (subject to NTP correction), monotomic time
On Sat, 10 Mar 2007, Nicholas Miell wrote:
> Try reading the timer_create man page.
>
> In short, you're limited to a single clock, so you can't set timers
> based on wall-clock time (subject to NTP correction), monotomic time
> (not subject to NTP, will not ever go backwards or skip ticks), the
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > > >
> > > > So extend the existing POSIX timer API to deliver expiry events via
On Fri, 2007-03-09 at 23:36 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
So extend the existing POSIX timer API to deliver expiry events via a
fd.
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Try reading the timer_create man page.
In short, you're limited to a single clock, so you can't set timers
based on wall-clock time (subject to NTP correction), monotomic time
(not subject to NTP, will not ever go backwards or skip ticks), the
On Sat, 2007-03-10 at 12:41 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Try reading the timer_create man page.
In short, you're limited to a single clock, so you can't set timers
based on wall-clock time (subject to NTP correction), monotomic time
(not
On Sat, 10 Mar 2007, Nicholas Miell wrote:
That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports. If if you think
extending it would be bad, I can show you the
On Sat, 2007-03-10 at 13:44 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
That's what the sigevent structure is for -- to describe how events
should be signaled to userspace, whether by signal delivery, thread
creation, or queuing to event completion ports. If
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I never complained about one timer per fd (although, now that you
mention it, that would get a bit excessive if you have thousands of
outstanding timers).
Right, of course.
The real-time and monotonic selection can be added.
IOW, the timerfd
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Care to elaborate on why they're a horrible crock?
It's a *classic* case of an interface that tries to do everything under
the sun.
Here's a clue: look at any system call that takes a union as part of its
arguments. Count them. I think we have
On Sat, 2007-03-10 at 14:42 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Care to elaborate on why they're a horrible crock?
It's a *classic* case of an interface that tries to do everything under
the sun.
Here's a clue: look at any system call that takes
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I'd actually much rather do POSIX timers the other way around: associate a
generic notification mechanism with the file descriptor, and then
implement posix_timer_create() on top of timerfd. Now THAT sounds like a
clean unix-like interface
On Sat, 2007-03-10 at 16:35 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
I'd actually much rather do POSIX timers the other way around: associate
a
generic notification mechanism with the file descriptor, and then
implement posix_timer_create() on
On Sat, 10 Mar 2007, Nicholas Miell wrote:
If that's the goal, somebody should start thinking about reducing the
contents of struct file to the bare minimum (i.e. not much more than a
file_operations pointer).
That's already pretty smal, and the single inode (and maybe dentry) will
make it
On Sat, 2007-03-10 at 17:57 -0800, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
If that's the goal, somebody should start thinking about reducing the
contents of struct file to the bare minimum (i.e. not much more than a
file_operations pointer).
That's already
On Sat, 10 Mar 2007, Linus Torvalds wrote:
(That said, using struct itimerspec might be a good idea. That would
also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically
has both base and incremental parts).
But TFD_TIMER_SEQ is a simple auto-rearm case of TFD_TIMER_REL. So
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Ah, I see. You're just interested in fds as a generic handle concept,
and not a more Plan 9 type thing.
Indeed. It's a handle.
UNIX has pid's for process handles, and file descriptors for just
about everything else.
If that's the goal, somebody
On Sat, 10 Mar 2007, Davide Libenzi wrote:
On Sat, 10 Mar 2007, Linus Torvalds wrote:
(That said, using struct itimerspec might be a good idea. That would
also obviate the need for TFD_TIMER_SEQ, since an itimerspec automatically
has both base and incremental parts).
But
On Sat, 10 Mar 2007, Linus Torvalds wrote:
Actually, the only place where I can find the itimerspec usefull, is
indeed with TFD_TIMER_SEQ. In cases where you want you clock starting at a
given time (it_value) *and* with the given frequency (it_interval).
.. and this is where itimerspec
On Sat, 2007-03-10 at 21:31 -0800, Linus Torvalds wrote:
On Sat, 10 Mar 2007, Nicholas Miell wrote:
Ah, I see. You're just interested in fds as a generic handle concept,
and not a more Plan 9 type thing.
Indeed. It's a handle.
UNIX has pid's for process handles, and file
On Fri, 9 Mar 2007, Nicholas Miell wrote:
> On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > >
> > > So extend the existing POSIX timer API to deliver expiry events via a
> > > fd.
> >
> > It'll be out of standard as timerfd is, w/out
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> > > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> > >
> > > > Why did you ignore the existing POSIX timer API?
> > >
> > > The
On Fri, 9 Mar 2007, Nicholas Miell wrote:
> On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> > On Fri, 9 Mar 2007, Nicholas Miell wrote:
> >
> > > Why did you ignore the existing POSIX timer API?
> >
> > The existing POSIX API is a standard and a very good one. Too bad it does
> >
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
> On Fri, 9 Mar 2007, Nicholas Miell wrote:
>
> > Why did you ignore the existing POSIX timer API?
>
> The existing POSIX API is a standard and a very good one. Too bad it does
> not deliver to files. The timerfd code is, as you can
On Fri, 9 Mar 2007, Nicholas Miell wrote:
> Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to files. The timerfd code is, as you can probably read from
the code, a really thin wrapper around the existing
On Fri, 2007-03-09 at 15:41 -0800, Davide Libenzi wrote:
> This patch introduces a new system call for timers events delivered
> though file descriptors. This allows timer event to be used with
> standard POSIX poll(2), select(2) and read(2). As a consequence of
> supporting the Linux f_op->poll
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op->poll subsystem, they can be used with
epoll(2) too.
The system call is
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op-poll subsystem, they can be used with
epoll(2) too.
The system call is
On Fri, 2007-03-09 at 15:41 -0800, Davide Libenzi wrote:
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op-poll
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to files. The timerfd code is, as you can probably read from
the code, a really thin wrapper around the existing
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to files. The timerfd code is, as you can probably
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a standard and a very good one. Too bad it does
not deliver to
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:38 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
Why did you ignore the existing POSIX timer API?
The existing POSIX API is a
On Fri, 9 Mar 2007, Nicholas Miell wrote:
On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote:
On Fri, 9 Mar 2007, Nicholas Miell wrote:
So extend the existing POSIX timer API to deliver expiry events via a
fd.
It'll be out of standard as timerfd is, w/out code savings. Look
50 matches
Mail list logo
