All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: davidm@hpl.hp.com
Cc: linux-kernel@vger.kernel.org, jim.houston@ccur.com
Subject: Re: POSIX timer syscalls
Date: Thu, 06 Mar 2003 17:39:16 -0800	[thread overview]
Message-ID: <3E67F844.2090902@mvista.com> (raw)
In-Reply-To: <15975.62823.5398.712934@napali.hpl.hp.com>

David Mosberger wrote:
>>>>>>On Thu, 06 Mar 2003 15:53:50 -0800, george anzinger <george@mvista.com> said:
> 
> 
>   George> I think there is a bit of a problem in the idr code
>   George> (.../lib/idr.c) which manages the id allocation.  Seems we
>   George> are returning "long" from functions declared as int.  If I
>   George> remember the code correctly this will work, but it does
>   George> eliminate the sequence number that should be in the high 8
>   George> bits of the id.
> 
> Yes.  We have had some reports of problems with POSIX timers and I
> suspect this might be the reason (though I don't know what the exact
> code-base was that the person reporting the problem was using).
> 
>   George> This assumes that you never allocate more than 2,147,483,647
>   George> timers at once :) I will look at this and send in a patch.
>   George> I think we should return what ever timer_t is, so we should
>   George> run that to ground first.
> 
> Yes, that would be better.  According to Uli, a 32-bit timer_t is fine
> as far as the standards are concerned.  That's good.
> 
>   George> I suspect we should also have a look at all the structures
>   George> with a view to alignment issues or is this not a problem?
>   George> I.e. is this struct ok:
> 
>   George> struct { long a; int b; long c; }
> 
> Such code may be OK correctnesswise, but to avoid wasting space, it's
> clearly better to list larger members first.

Ok, I will fix all the above and shoot you a patch.  I assume you can 
test it on a 64-bit platform.  Right?

-g
> 
> 	--david
> 
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


  reply	other threads:[~2003-03-07  1:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-06 23:06 POSIX timer syscalls David Mosberger
2003-03-06 23:53 ` george anzinger
2003-03-07  1:27   ` David Mosberger
2003-03-07  1:39     ` george anzinger [this message]
2003-03-07  1:42       ` David Mosberger
2003-03-07  8:24         ` george anzinger
2003-03-07 10:09           ` Eric Piel
2003-03-07 12:14           ` Eric Piel
2003-03-07 18:16             ` george anzinger
2003-03-07 18:20             ` george anzinger
2003-03-07  0:15 ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E67F844.2090902@mvista.com \
    --to=george@mvista.com \
    --cc=davidm@hpl.hp.com \
    --cc=jim.houston@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.