[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: FW: [RFC] A more general timeout specification

On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:

> I cannot produce (top of my head) any other POSIX API calls that
> allow you to specify another clock source, but they are there,
> somewhere. If I am to introduce a new API, I better make it
> flexible enough so that other subsystems can use it for more stuff
> other than...

So we have to deal at kernel level with every broken timeout specification
that comes along?

> >Why is not sufficient to just add a relative/absolute version,
> >which convert the time at entry to kernel time?
> ...adding more versions that add complexity and duplicate
> code in many different places (user-to-kernel copy, syscall entry
> points, timespec validation). And the minute you add a clock_id
> you can steal some bits for specifying absolute/relative (or vice
> versa), so it is almost a win-win situarion.

What "more versions" are you talking about? When you convert a user time
to kernel time you can automatically validate it and later you can use
standard kernel APIs, so you don't have to add even more API bloat.

bye, Roman
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-01 01:55    [W:0.065 / U:2.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site