Arjan van de Ven wrote:
This one I meant to fix in the kernel fwiw; we can put that loop inside
the kernel easily I'm sure
Yes, but it will increase the data size of the timer...
eh how?
the way I think it can be done is to just have multiple timers fire
until the total time is up. It's not a perf
> >
> > This one I meant to fix in the kernel fwiw; we can put that loop inside
> > the kernel easily I'm sure
>
> Yes, but it will increase the data size of the timer...
>
eh how?
the way I think it can be done is to just have multiple timers fire
until the total time is up. It's not a perfor
Arjan van de Ven wrote:
On Wed, 2005-01-19 at 15:51 -0800, George Anzinger wrote:
Arjan van de Ven wrote:
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
Matthias Lang <[EMAIL PROTECTED]> wrote:
These are things we probably cannot change now.
On Wed, 2005-01-19 at 15:51 -0800, George Anzinger wrote:
> Arjan van de Ven wrote:
> > On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
> >
> >>On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
> >>
> >>>Matthias Lang <[EMAIL PROTECTED]> wrote:
> >>>These are things we probably cannot change no
Arjan van de Ven wrote:
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
Matthias Lang <[EMAIL PROTECTED]> wrote:
These are things we probably cannot change now. All three are arguably
sensible behaviour and do satisfy the principle of least surp
On Sun, 2005-01-16 at 00:58 +, Alan Cox wrote:
> On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
> > Matthias Lang <[EMAIL PROTECTED]> wrote:
> > These are things we probably cannot change now. All three are arguably
> > sensible behaviour and do satisfy the principle of least surprise. So
On Sad, 2005-01-15 at 09:30, Andrew Morton wrote:
> Matthias Lang <[EMAIL PROTECTED]> wrote:
> These are things we probably cannot change now. All three are arguably
> sensible behaviour and do satisfy the principle of least surprise. So
> there may be apps out there which will break if we "fix"
Matthias Lang wrote:
Chris Wedgewood suggested handling this with a printk, to which Arjan
van de Ven asked
> but why
>
> if someone wants the stuff rejected in a posix confirm way, he can do
> these tests easily in the syscall wrapper he needs anyway for this
> function.
For negative
Chris Wedgewood suggested handling this with a printk, to which Arjan
van de Ven asked
> but why
>
> if someone wants the stuff rejected in a posix confirm way, he can do
> these tests easily in the syscall wrapper he needs anyway for this
> function.
For negative times and oversized
On Sat, 2005-01-15 at 11:55 -0800, Chris Wedgwood wrote:
> On Sat, Jan 15, 2005 at 10:58:45AM +0100, Arjan van de Ven wrote:
>
> > I don't see a valid reason to restrict/reject input that is accepted
> > now and dealt with reasonably because some standard says so (if you
> > design a new api, foll
On Sat, Jan 15, 2005 at 10:58:45AM +0100, Arjan van de Ven wrote:
> I don't see a valid reason to restrict/reject input that is accepted
> now and dealt with reasonably because some standard says so (if you
> design a new api, following the standard is nice of course). I don't
> see "doesn't rejec
On Sat, 2005-01-15 at 01:36 -0800, William Lee Irwin III wrote:
>> We can easily do a "rolling upgrade" by adding new versions of the
>> system calls, giving glibc and apps grace periods to adjust to them,
>> and nuking the old versions in a few years.
On Sat, Jan 15, 2005 at 10:58:45AM +0100, Arj
On Sat, 2005-01-15 at 01:36 -0800, William Lee Irwin III wrote:
> Matthias Lang <[EMAIL PROTECTED]> wrote:
> >> The linux implementation of setitimer() doesn't behave quite as
> >> expected. I found several problems:
> >>1. POSIX says that negative times should cause setitimer() to
> >>
Matthias Lang <[EMAIL PROTECTED]> wrote:
>> The linux implementation of setitimer() doesn't behave quite as
>> expected. I found several problems:
>>1. POSIX says that negative times should cause setitimer() to
>> return -1 and set errno to EINVAL. In linux, the call succeeds.
>>2.
Matthias Lang <[EMAIL PROTECTED]> wrote:
>
> The linux implementation of setitimer() doesn't behave quite as
> expected. I found several problems:
>
>1. POSIX says that negative times should cause setitimer() to
> return -1 and set errno to EINVAL. In linux, the call succeeds.
>
>
Hi,
The linux implementation of setitimer() doesn't behave quite as
expected. I found several problems:
1. POSIX says that negative times should cause setitimer() to
return -1 and set errno to EINVAL. In linux, the call succeeds.
2. POSIX says that time values with usec >= 100 shou
16 matches
Mail list logo
