atomic wrt what ? i assumed you were talking inter-threads. the atomic you
refer to there is inter-process, not inter-threads.
Should writing into a pipe not be atomic with threads, too, if each
thread did it's own open() ?
-Michael
___
Also,
code which depends on vfork behaviour isn't portable except for a few
things which are allowed.
What do you mean by portable ? Is the vfork() behavior not well
defined across different archs ? Or do you mean not portable to archs
that do have fork(). If so, why not continue to use
On Monday 02 March 2009 03:25:01 Michael Schnell wrote:
Also,
code which depends on vfork behaviour isn't portable except for a few
things which are allowed.
What do you mean by portable ? Is the vfork() behavior not well
defined across different archs ? Or do you mean not portable to
On Monday 02 March 2009 03:08:23 Michael Schnell wrote:
atomic wrt what ? i assumed you were talking inter-threads. the atomic
you refer to there is inter-process, not inter-threads.
Should writing into a pipe not be atomic with threads, too, if each
thread did it's own open() ?
You should not do _anything_ with threads in a vfork child.
pthread_self() is not safe. Thread-local variables are not safe to
acccess.
Hmm, I suppose, in a non-MMU system, any user process is started by the
shell using vfork(), So obvious there are situations where you are
allowed to do
On Monday 02 March 2009 03:57:34 Michael Schnell wrote:
You should not do _anything_ with threads in a vfork child.
pthread_self() is not safe. Thread-local variables are not safe to
acccess.
Hmm, I suppose, in a non-MMU system, any user process is started by the
shell using vfork(), So
It is possible to daemonize on uClinux without exec'ing a new process,
using clone() instead of vfork(). I have a version of the daemon()
function which does that, which I posted to the Busybox bug tracker
years ago; I should really submit it to uClibc.
I found that with the arch I use (NIOS),
i believe David Howells has down a lot of work to get futex's working on no-
mmu. but that doesnt mean the syscall has been added and people have actually
tested it yet ...
I'd really love to do the necessary code and/or testing for the NIOS
arch. So do you have a pointer where I should
Don't call
functions like printf or malloc, or exit.
I suppose with exit you mean reach the end of the function. Of course
you are allowed to close the running (child-) process by calling the
appropriate library function (exit() ?) .#
-Michael
Am Montag, den 02.03.2009, 10:14 +0100 schrieb Michael Schnell:
It is possible to daemonize on uClinux without exec'ing a new process,
using clone() instead of vfork(). I have a version of the daemon()
function which does that, which I posted to the Busybox bug tracker
years ago; I should
Am Montag, den 02.03.2009, 11:55 +0100 schrieb Michael Schnell:
the '-d' option for boa is a no-op in uClinux, the fork call is #ifdef'd
out. Just using boa will do the job.
This is true with the old version (0.93) The NIOS uClinux-dist by
default activated boa by boa
When they moved
In fact I suppose it makes sense to do auto-daeminizing code in an
application only to save the users some work when calling the
application _not_ from a shell. With a shell you always can use the .
How do you want to do that in uClinux?
Provide what ?
The usual approach for MMU
Michael Schnell wrote:
Also, code which depends on vfork behaviour isn't portable except
for a few things which are allowed.
What do you mean by portable ? Is the vfork() behavior not well
defined across different archs ? Or do you mean not portable to archs
that do have fork(). If so,
Mike Frysinger wrote:
all documentation on vfork() is very clear: the only thing you can rely on
portably after a vfork() is to call _exit() or an exec() function.
That's what POSIX says. It turns out even that may not be safe: some
versions of Glibc call malloc() and realloc() inside
Michael Schnell wrote:
BTW.: AFAIK, clone() called with the appropriate arguments performs the
same action as fork() or vfork(). Thus, does fork() or vfork() just call
clone() ? Is the behavior of clone() (e.g. if or if not stall the parent
process until the child does *exec() or exit )
Michael Schnell wrote:
Don't call
functions like printf or malloc, or exit.
I suppose with exit you mean reach the end of the function. Of course
you are allowed to close the running (child-) process by calling the
appropriate library function (exit() ?) .#
I mean don't call exit()
Many thanks for your explanations. I'll store this for reference.
Jamie Lokier wrote:
- The child code must not return from the function which calls
vfork; must not call longjmp and similar functions; must not
call malloc and similar functions; must not call printf and
other
To daemonize, you don't use the same flags as you would to emulate
fork() and vfork(), and have to use a little arch-specific assembler.
Fully that you need to do this manually. Daemonizing seems quite common,
so I would have expected to find it in glibc or such.
-Michael
Michael Schnell wrote:
futex mutexes should be easy. The harder bit is TLS. Switching to
NPTL implies both, as far as I know.
Sorry for my ignorance. What is TLS and what are the implications ? Do
you have any pointers ? There are several requests for NPTL on
NIOS-arch. I don't
Hello,
I am working on LPC2292 board,
and i ask if you can give :
* linux-2.6.25-lpc22xx.patch.gz (else = 2.6.20)
* uClinux-dist-lpc22xx.patch.gz
Kind regards
Lafi Ghanem
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
TLS Thread Local Storage is the ability to say
int __thread i;
I see ! Does using TLS create fast code or will there be a library
call done for any access to i ?
When I was thinking about the multithreaded application I am planning, I
found that I need a thread to know some
NPTL's advantages over LinuxThreads which come to mind:
- Faster to communicate between threads because it doesn't use signals.
Do you suggest, the pthread library does any IPC using signals ? There
are a lot other means (semaphores, message queues, ...)
- Futex-based primitives mean
On Sat, Feb 28, 2009 at 08:29:32PM +, Jamie Lokier wrote:
It's probably easier to look at the GCC source itself, look at what
oldabi sets differently.
Perhaps. Of course it would be nice of gcc 4.3 actually built when
configured for oldabi, but it doesn't. If it did I could actually find
On Mon, Mar 02, 2009 at 09:19:22AM +0100, Michael Schnell wrote:
create a pipe
vfork
in child change stdout and stderr to one end of the pipe
exec a new program that now uses the pipe as it's output
now in the main program read from the pipe to get the output.
Will the child do *exec()
Yeah that would certainly be undesired. I figure the exec should happen
as soon as possible after the vfork.
Usually exec() in fact is the next C-line after vfork(), so there would
be no time(slice) to execute anything else in between, anyway.
-Michael
Yeah that would certainly be undesired. I figure the exec should happen
as soon as possible after the vfork.
Usually exec() in fact is the next C-line after vfork(), so there would
be no time(slice) to execute anything else in between, anyway.
(exec() is done by the _child_ )
-Michael
Michael Schnell wrote:
TLS Thread Local Storage is the ability to say
int __thread i;
I see ! Does using TLS create fast code or will there be a library
call done for any access to i ?
On most architectures it uses a CPU register, so no library call. On
some ARMs it uses a
On Monday 02 March 2009 09:34:20 Michael Schnell wrote:
NPTL's advantages over LinuxThreads which come to mind:
- Faster to communicate between threads because it doesn't use signals.
Do you suggest, the pthread library does any IPC using signals ? There
are a lot other means (semaphores,
Michael Schnell wrote:
NPTL's advantages over LinuxThreads which come to mind:
- Faster to communicate between threads because it doesn't use signals.
Do you suggest, the pthread library does any IPC using signals ? There
are a lot other means (semaphores, message queues, ...)
Mike Frysinger wrote:
there was some support in later glibc versions for TLS
in linuxthreads as well ...
Oh, that's interesting, thanks. I didn't know that.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
On Monday 02 March 2009 09:57:14 Michael Schnell wrote:
Yeah that would certainly be undesired. I figure the exec should happen
as soon as possible after the vfork.
Usually exec() in fact is the next C-line after vfork(), so there would
be no time(slice) to execute anything else in
Mike Frysinger wrote:
I see ! Does using TLS create fast code or will there be a library
call done for any access to i ?
i dont know of any port that implements TLS via a library call, but how each
port does TLS is highly port specific
ARM uses a function call to a kernel page,
On Monday 02 March 2009 08:37:05 Michael Schnell wrote:
Jamie Lokier wrote:
- The child code must not return from the function which calls
vfork; must not call longjmp and similar functions; must not
call malloc and similar functions; must not call printf and
other stdio
It's available on some uClinux systems. You can add support to yours,
be my guest :-)
Tomorrow I'll do a test if it's available.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
It's possible to implement TLS in LinuxThreads if you want.
Nobody has done so; there's no point because it's easier to port NPTL.
So my system will not have TLS :(
OK, let's do NPTL :)
Are you thinking of a different kind of mutex?
I _thought_ this would have been meant
in our context of Linux and doing it right,
TLS is the way to go
But if the port does not have it.
(I want to port a multithreaded program from a propriety OS and as the
Linux interprocess sync is slow, I hoped to be able to do a user-land
inter-thread sync based on Futex. But now I
On Mon, Mar 02, 2009 at 11:58:39AM -0500, Lennart Sorensen wrote:
On Sat, Feb 28, 2009 at 10:24:00AM +1000, Greg Ungerer wrote:
Send the disassemblies to this list. Someone might be able to spot
a problem.
OK, slightly large but here goes.
I have compiled with gcc 4.1.1 + uclibc 0.9.27
Michael Schnell wrote:
in our context of Linux and doing it right,
TLS is the way to go
But if the port does not have it.
(I want to port a multithreaded program from a propriety OS and as the
Linux interprocess sync is slow, I hoped to be able to do a user-land
inter-thread sync
Michael Schnell wrote:
To daemonize, you don't use the same flags as you would to emulate
fork() and vfork(), and have to use a little arch-specific assembler.
Fully that you need to do this manually. Daemonizing seems quite common,
so I would have expected to find it in glibc or such.
Michael Schnell wrote:
In my understanding to implement FUTEX, the arch either needs to provide
an appropriate monolithic memory operation (e.g. load and inc or test
and set), or needs to be non-SMP and allow for disable/enable
interrupts directly in user-space. (The second option seems to
On Feb 25, 2009, at 2:36 PM, Lennart Sorensen wrote:
So does gcc 4.3.x work for anyone on m68knommu with uClibc? Am I
trying
something hopeless here, or am I just configuring or compiling it
wrong
perhaps.
Sorry, I'm late to the thread.
We're using gcc 4.3.1 with uClibc snapshot
On Mon, Mar 02, 2009 at 02:46:04PM -0500, Allon Stern wrote:
On Feb 25, 2009, at 2:36 PM, Lennart Sorensen wrote:
So does gcc 4.3.x work for anyone on m68knommu with uClibc? Am I
trying
something hopeless here, or am I just configuring or compiling it
wrong
perhaps.
Sorry, I'm late
Hi,
We have been working with the uclinux distribution made on 2008/08/08.
It appears the uclibc included in this distro is a version made
around 2005. Is that true?
Specifically we have found a bug that was already fixed in 2006,
but still missing in this version of uclibc.
What determines
The uClibc that comes with uClinux-dist is rather old.
I upgraded my local copy of uClinux-dist with the uClibc source from the
Codesourcery toolchain for Coldfire. This fixed some strange timing bugs
I found after activating CPU cache.
I think that uClinux-dist still contains an old uClibc
On Monday 02 March 2009 12:39:07 Jamie Lokier wrote:
Michael Schnell wrote:
To daemonize, you don't use the same flags as you would to emulate
fork() and vfork(), and have to use a little arch-specific assembler.
Fully that you need to do this manually. Daemonizing seems quite common,
Hi Lennart,
Lennart Sorensen wrote:
On Sat, Feb 28, 2009 at 10:24:00AM +1000, Greg Ungerer wrote:
Send the disassemblies to this list. Someone might be able to spot
a problem.
OK, slightly large but here goes.
I have compiled with gcc 4.1.1 + uclibc 0.9.27 which works and with gcc
4.3.2 +
Hi Richard,
Richard Retanubun wrote:
From 0bad7aa337cf16bed99f5f71613e587f61068dde Mon Sep 17 00:00:00 2001
From: Richard Retanubun richardretanu...@ruggedcom.com
Date: Mon, 9 Feb 2009 10:41:48 -0500
Subject: [PATCH] Fixed GPIO pin initialization for CONFIG_M5271 FEC.
This processor only have
47 matches
Mail list logo
