In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: > and the priority argument of tsleep() doesn't have any meaning
: > any longer, right?
: >
:
: I thought it did, but John can give the definitive answer.
Priority is still useful. It is the same priority that
Hello hackers,
man page for flock(2) and fcntl(2) reads that a system call returns
EOPNOTSUPP if file descriptor refers to an object that does not support
file locking.
However, it seems that it is not always true. For example, if underlying
object is a device or a fifo returned error code d
Hi,
> > Being full of enthusiasm, I checked if by chance libraries could have
> > dynamic object dependencies. It appears this is not the case, but
> > since I'm neither a GCC nor binutils hacker, maybe there is a way to
> > achieve this. This is the purpose of this email ?
>
> What you have be
On 7/26/05, David Malone <[EMAIL PROTECTED]> wrote:
> That's correct, but it probably takes a few microseconds for the
> carries sense to kick in (if there wasn't a delay there would
> be almost no need for the random backoff). That's why you'll
> also have to have your transmissions synchronised v
On 7/21/05, Sam Leffler <[EMAIL PROTECTED]> wrote:
> You need to set cwmin on the tx q as David describes. Be sure to set
> the parameters you set into the hardware; check the wme update code for
> the correct logic. For the other thing just set the tx descriptor to do
> 1 try.
>
> Sam
On Wed, 27 Jul 2005, Scott Long wrote:
> Daniel Eischen wrote:
>
> >
> > My mistake then. I thought they were deprecated when mutex and
> > CVs were introduced. There is no need for them except for compatability,
>
> Incorrect. A mutex is not a replacement for sleep. CV's and semaphores
> impl
Daniel Eischen wrote:
On Wed, 27 Jul 2005, Scott Long wrote:
Daniel Eischen wrote:
On Wed, 27 Jul 2005, Norbert Koch wrote:
The functions await() and asleep() in kern_synch.c
are marked as EXPERIMENTAL/UNTESTED.
Is this comment still valid? Does anyone have used
those functions successf
On Wed, 27 Jul 2005, Scott Long wrote:
> Daniel Eischen wrote:
> > On Wed, 27 Jul 2005, Norbert Koch wrote:
> >
> >
> The functions await() and asleep() in kern_synch.c
> are marked as EXPERIMENTAL/UNTESTED.
> Is this comment still valid? Does anyone have used
> those functions suc
Daniel Eischen wrote:
On Wed, 27 Jul 2005, Norbert Koch wrote:
The functions await() and asleep() in kern_synch.c
are marked as EXPERIMENTAL/UNTESTED.
Is this comment still valid? Does anyone have used
those functions successfully? Should I better not
use them in my device driver code for RELE
On Wed, 27 Jul 2005, Norbert Koch wrote:
> > > The functions await() and asleep() in kern_synch.c
> > > are marked as EXPERIMENTAL/UNTESTED.
> > > Is this comment still valid? Does anyone have used
> > > those functions successfully? Should I better not
> > > use them in my device driver code for
> You see, in C, I call the function like this (for example):
>
> void pic16l_setled(unsigned int val);
> pic16l_setled (0x1234);
>
> And it gets assembled to:
>
> pushl $0x1234
> callpic16l_setled
>
> But it should be assembled to:
>
> pushl $0x1234
>
Hi Ludvig,
* Ludvig Strigeus ([EMAIL PROTECTED]) wrote:
> Hi!
>
> I see this code:
>
> +ENTRY(pic16l_setled)
> + push%ebp
> + mov %esp,%ebp
> +
> + movl0x8(%ebp),%ebx
> + orl $0x800,%ebx
> + callpic16l_ledhlp
> + movl$0x701,%ebx
> + callpic
On Tue, Jul 26, 2005 at 06:46:55PM -0400, jason henson wrote:
> To avoid this warning, the variables and/or arguments should be
> prevented from being optimized by declaring them as volatile.
>
> So I sprinkled some volatiles around, but mostly got more errors that
> said "gcc volatile discard
Rink Springer <[EMAIL PROTECTED]> writes:
> Hello everyone,
>
> Over the last 2 weeks, I have been working on a port of FreeBSD for the
> XBox. During this effort, Ed Schouten has given me assistance by
> reviewing patches and giving advice.
>
Great, thanks for your work.
I got my XBOX with an
14 matches
Mail list logo
