Mike Frysinger wrote:
as it stands, this breaks all non-arm NOMMU ports. the patch will need to be
broken up into arm-specific and arm-independent parts.
the common code changes will need justification as to why they exist at all.
we're doing MPU on Blackfin/nommu today without any of
Philippe De Muyter wrote:
On Tue, May 25, 2010 at 12:20:47AM +0100, Jamie Lokier wrote:
Philippe De Muyter wrote:
On Mon, May 24, 2010 at 06:26:08PM +0100, Jamie Lokier wrote:
Philippe De Muyter wrote:
On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote:
Philippe De
Philippe De Muyter wrote:
On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote:
Philippe De Muyter p...@macqel.be wrote:
+#else
+#define TASK_SIZE (0xUL)
+#endif
Because of do_getname() :
len = TASK_SIZE - (unsigned long) filename;
we
David Howells wrote:
Jamie Lokier ja...@shareable.org wrote:
TASK_SIZE is the wrong kind of check on no-MMU: A better check is that
the address is within the userspace mappable address range, whatever
that is, which may start at some value and end at some other value,
and may have holes
Philippe De Muyter wrote:
On Mon, May 24, 2010 at 06:26:08PM +0100, Jamie Lokier wrote:
Philippe De Muyter wrote:
On Mon, May 24, 2010 at 04:59:18PM +0100, David Howells wrote:
Philippe De Muyter p...@macqel.be wrote:
+#else
+#define TASK_SIZE (0xUL
Lennart Sorensen wrote:
On Thu, May 06, 2010 at 10:12:27AM +0900, Zaya Kh wrote:
Hi , all
I want to create uClinux with Asterisk PBX, I'm using Petalinux tool chain
and Spartan3e Starter kit board
We can* make menuconfig*,
check Asterisk PBX, and libSSL, ncurses
While we
Mike Frysinger wrote:
i'm not sure if this is a Blackfin thing, but the first arg to execve() isnt
decoded correctly. also, the forked programs hit the PANIC code instead of
decoding the exit ? for example, the above strace shows:
[pid 228] execve(NULL, [0x2a0e520], [/* 0 vars */]) = 0
Jeff Bacon wrote:
On 4/21/2010 11:57 AM, Jamie Lokier wrote:
Jeff Bacon wrote:
On 4/21/2010 11:04 AM, Lennart Sorensen wrote:
What version of Busybox are you using? I am finding it difficult to make
a newer version (1.15.x, 1.16.0) that small. In fact, when I configure
Lennart Sorensen wrote:
On Wed, Apr 21, 2010 at 11:34:35AM -0400, Jeff Bacon wrote:
I was under the impression that for NOMMU, binary Text segments could
NOT be shared. How are you getting the kernel to share the text areas?
For me, every copy of BB is taking up a new 256kB chunk. I am
Jeff Bacon wrote:
On 4/21/2010 11:44 AM, Jamie Lokier wrote:
I was under the impression that for NOMMU, binary Text segments could
NOT be shared. How are you getting the kernel to share the text areas?
For me, every copy of BB is taking up a new 256kB chunk. I am running
on an ARM7TDMI
, but instead of exiting
the child called execve() and the exec'd process waits another second.
This shows vfork not returning until the child calls execve(), and then
returning while the child continues to run for another second.
Signed-off-by: Jamie Lokier ja...@shareable.org
---
test/Makefile
fork and vfork to clone equivalents,
and vfork to fork, just leave them as they are. Always return with
tcp-u_arg[arg0_index] set to appropriate clone flags in all cases,
even if clone wasn't actually used.
Signed-off-by: Jamie Lokier ja...@shareable.org
---
util.c | 53
PTRACE_EVENT_{FORK,VFORK,CLONE} and needs the new
function to be separate.
* process.c [LINUX] (internal_fork_child): New function.
* defs.h [LINUX] (internal_fork_child): Declare.
* defs.h (struct tcb): Rearrange so the LINUX ifdef can omit -baddr.
Signed-off-by: Jamie Lokier ja...@shareable.org
-off-by: Jamie Lokier ja...@shareable.org
---
defs.h|5 +++--
process.c | 51 ---
2 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/defs.h b/defs.h
index ab69a45..fadbd92 100644
--- a/defs.h
+++ b/defs.h
@@ -403,11 +403,12
to attach to the child.
Signed-off-by: Jamie Lokier ja...@shareable.org
---
process.c |5 ++---
strace.c | 35 +++
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/process.c b/process.c
index e46957d..bfc4c9d 100644
--- a/process.c
+++ b
* process.c [LINUX] (clone_flags): Add decoding of flags
CLONE_STOPPED, CLONE_NEWUTS, CLONE_NEWIPC, CLONE_NEWUSER,
CLONE_NEWPID, CLONE_NEWNET and CLONE_IO. Also tidy the
whitespace a bit.
Signed-off-by: Jamie Lokier ja...@shareable.org
---
process.c | 48
Mike Frysinger wrote:
On Thursday 21 January 2010 20:21:31 Jamie Lokier wrote:
Mike Frysinger wrote:
GCC-2.x has a bug with empty arg expansion in macros.
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ## args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ## args
Mike Frysinger wrote:
GCC-2.x has a bug with empty arg expansion in macros.
if (lvl = DEBUG) { \
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ##
args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ##
args); \
Michael Schnell wrote:
thiago wrote:
Is there a tool that simulates platforms that I can use to test my
kernel build?
I suppose this depends on the hardware you are intending to have the
Kernel run on. (X86: VMWare, Virtual Box,... ; ARM: Armulator, ...; ...)
See also Qemu, which
Mike Frysinger wrote:
when posting updates, you should put the v2 and such inside of the
[patch] marker like so: [PATCH v2]. git will remove this
automatically when applying.
Thanks; I didn't know this.
On Thursday 31 December 2009 20:26:45 Jun Sun wrote:
#define
Jun Sun wrote:
(Sent to linux-kernel, but seems nobody cared. Hopefully someone here
can pick it up)
I've included uclinux-dev@uclinux.org, because that's where I've seen
most discussion of FLAT format in general.
Apparently newer GCC would generate ANCHOR symbols beyond the end of
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just in case it turns out something
important was overlooked?
-- Jamie
Hi Greg,
Greg Ungerer wrote:
The non-MMU ARM is more tricky. I try to keep the uClinux-dist
ARM no-mmu targets working (well at least GDB/ARMulator/Skyeye).
But it is very much on a as-time-permits basis for me.
Ironically, I've just spent nearly a day trying to get the
GDB/Armulator or
Greg Ungerer wrote:
Hi Jamie,
On 12/17/2009 11:45 PM, Jamie Lokier wrote:
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just
Lennart Sorensen wrote:
On Tue, Dec 15, 2009 at 10:11:27PM +1000, Greg Ungerer wrote:
Have I missed the right repo, or isn't there one?
That kernel is really just a compilation of lots of other trees
(mostly vendors trees), almost none of which are git trees.
Much of the change in there
Mike Frysinger wrote:
On Saturday 12 December 2009 00:12:19 Jamie Lokier wrote:
I'm looking for a Git repository which corresponds to the kernel in
the uClinux distribution, to see the changes with history in a
cherry-pickable form. Is there a repository?
i dont know what you're looking
Hi all,
I'm looking for a Git repository which corresponds to the kernel in
the uClinux distribution, to see the changes with history in a
cherry-pickable form. Is there a repository?
The uClinux distribution I'm looking at is:
Jamie Lokier wrote:
For Git repositories, I looked around and found these which were
mentioned at various times and sounded promising:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-2.6-nommu.git
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
Jie Zhang wrote:
On 11/25/2009 02:16 PM, Jamie Lokier wrote:
Mike Frysinger wrote:
From: Jie Zhangjie.zh...@analog.com
The mmu code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing
Mike Frysinger wrote:
From: Jie Zhang jie.zh...@analog.com
The mmu code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch
ucli...@browserseal.com wrote:
Please note that people new to uClinux are most likely to use
Codesourcery toolchain, rather than 2007 one from uClinux web site.
Fwiw, on the ARM linux lists, Codesourcery is usually the recommended
toolchain, not the 2007 uClinux toolchain or any of the many
Steve Bennett wrote:
The only way
you can achieve the appearance of asynchronous responses
from the server is via polling, with all the attendant downsides. One
approach is to use AJAX as a way of minimising the polling traffic,
but it is still polling.
No, that is not true.
Mike Frysinger wrote:
On Wednesday 14 October 2009 05:08:08 Cappelletti Fabio wrote:
Hi all, I'm tying to write a simple hush script , but I have a lot of
problem with two commands : expr and cat!
In particula my script is as follow:
#!/bin/hush
A= `cat /proc/driver/cardtype/BoardAddr`
micro...@virginbroadband.com.au wrote:
Just about any consumer device today has ARM in it.
Last I heard, most video set top boxes / PVRs have MIPs inside.
MIPS seems to be popular in home routers routers too.
-- Jamie
___
uClinux-dev mailing list
Michael Schnell wrote:
Seemingly the best instruction to handle these bits is atomic compare
and exchange (e.g. provided by the X86 CPU).
It's actually not the best, because when it returns did not match
you have to loop and try again.
The supposedly best user space implementation
Michael Schnell wrote:
Jamie Lokier wrote:
That's right. It's possible to use atomic_compare_and_exchange for
unlock; it's correct. But you get that extra bit of spinning with SMP,
so atomic_dec is better.
In fact I don't see why Ulrich did the unlock code like
Michael Schnell wrote:
I now have a Futex testing program up and running.
You may wish to look at Glibc's pthread tests too.
They did a lot of testing to make sure the NPTL futex usage is correct
with all kind of primitives, not just thread mutexes, but condition
variables, rwlocks, and
Michael Schnell wrote:
Michael Schnell wrote:
disables the global interrupt for the next three
instructions.
True for the NIOS, that does not use Flags - but register compares -
for conditional jumps, with an architecture that uses flags, I suppose
you need a lock for four instructions.
Jamie Lokier wrote:
Although compare-exchange is universal, sometimes it takes more time
busy spinning compared with an atomic arithmetic or logical operation,
when under high contention with multiple CPUs.
I'm being a bit stupid here. The interrupt-disabling method doesn't
work with multiple
Michael Schnell wrote:
Jim Donelson wrote:
All that is really required is an atomic exchange.
Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I got
back a zero, it's mine.
True with a Mutex, not true with a Futex. Here you need a second bit in
user-space that tells
Jim Donelson wrote:
It's actually not the best, because when it returns did not match
you have to loop and try again.
Not sure what else you would do? The purpose of a spin lock is to
avoid a more expensive kernel call
It's not a spinlock.
This loop is for a different reason. You can tell
Jim Donelson wrote:
I'd like to see the code for compare_exchange and the lock function.
compare_exchange is a single architecture-specific instruction; that's
what we're discussing. Lock functions are described in Ulrich
Drepper's futex paper.
The purpose of a spin lock is to avoid a
Jim Donelson wrote:
All that is really required is an atomic exchange.
Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I
got back a zero, it's mine.
Fine in theory.
ARM has an instruction like that, called SWP, and I've written mutex
code with it.
It turns out to
Michael Schnell wrote:
Jamie Lokier wrote:
You can't implement futex just by touching bits in a processor
register - the whole point of futex is to have lots of different
memory locations representing different locks.
You can do a single (or a few) FUTEX using processor bits. This done
Michael Schnell wrote:
The vsyscall trick is a good one, and works with/without MMU, and
with/without permission to disable interrupts in userspace.
Unfortunately I don't find something about the vsyscall trick in the
Kernel sources not in the glibC sources.
Look in
Michael Schnell wrote:
Let's assume you have a single CPU and no special atomic instructions.
- Copy the trick used on ARM to implement atomic-compare-exchange
in the vsyscall page, without disabling interrupts.
Modern ARM variants have load-Link / Store-Conditional
Michael Schnell wrote:
Jamie Lokier wrote:
Look in arch/arm/kernel/entry-armv.S for __kernel_cmpxchg,
kuser_cmpxchg_fixup, and all the places where kuser_cmpxchg_fixup is
called in that file.
Here they say:
/*
* The only thing that can break atomicity in this cmpxchg
Michael Schnell wrote:
Jim Donelson wrote:
this pair of instructions are basically an atomic test-and-set on the
microblaze status register.
An atomic operation on some dedicated bits located in the processor
rather than in memory. This is exactly what I intended to do for adding
Jim Donelson wrote:
Would disabling / enabling the interrupt be possible in user mode
(especially when running MMU enabled full Linux ?
That would depend on the arch of the MCU - May or may not be
enforceable by the kernel.
What should be done is that a mutex object should do
Jamie Lokier wrote:
However if you can implement a conditional-store which depends on
a custom flag, you can clear the flag on interrupt entry or exit in
the kernel.
And if you can do that, you can probably make the custom CPU clear the
flag _automatically_ on return-from-interrupt
Michael Schnell wrote:
I don’t think the uClibc that I have supports futexes as there is
a note in its TODO to add support for futexes.
If you use a noMMU architecture it might be quite easy to do the FUTEX,
as you can disable and re-enable the global Interrupt in a userland
application
Su Zhenbing wrote:
Hi guys,
I'm working on Sigma 8622 platform now and encounter a problem when I
porting some app to the uclinux.
Follow error always show even the source can compile pass.
-
Mike Frysinger wrote:
From: Jie Zhang jie.zh...@analog.com
The Blackfin port has custom program header flags/addresses for
automatically loading regions into the dedicated on-chip SRAM. So add a
hook for ports to leverage.
What does this have to do with FDPIC? I don't see anything that is
Mike Frysinger wrote:
On Sat, Jun 13, 2009 at 12:13, Jamie Lokier wrote:
Mike Frysinger wrote:
From: Jie Zhang jie.zh...@analog.com
The Blackfin port has custom program header flags/addresses for
automatically loading regions into the dedicated on-chip SRAM. So add a
hook for ports
Jamie Lokier wrote:
Wouldn't you still want to put some things into local L1 SRAM, using thos,
perhaps by
flagging it instead of
...
Aiee, slipped on the keyboard. Ignore.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http
Michael Schnell wrote:
AFAIK, there also are database server programs that just use RAM instead
of files or disks to store the data.
Yes. Good RAM databases use a different format in RAM than on disk
because the performance characteristics are so different.
-- Jamie
Alexander Stein wrote:
I also read about FDELF_PIC, but according to Greg it is only
supported on FRV and Blackfin. What is needed to be done, to get
FDELF_PIC supported on Coldfires (m68k in general). AFAIK there is
no distinction bewteen MMU and NOMMU with this type of binary. What
would be
Lennart Sorensen wrote:
Bittornado is python. Does python run on uclinux?
I read enough of a rumour that Python doesn't run on MMU-less uClinux
that I didn't bother to try.
I guess it might work on MMU-less architectures with FDPIC-ELF,
and of course uClinux tends to include MMUs now.
--
David McCullough wrote:
I read enough of a rumour that Python doesn't run on MMU-less uClinux
that I didn't bother to try.
I guess it might work on MMU-less architectures with FDPIC-ELF,
and of course uClinux tends to include MMUs now.
Actually, it has little to do with the
Lennart Sorensen wrote:
On Wed, Apr 22, 2009 at 11:05:13PM +1000, David McCullough wrote:
There's a good reason that only sash and the minix shell work on !MMU,
and the initially the minix shell needed a fair bit of work to make safe
on !MMU :-)
Seems to work very well now though.
Lennart Sorensen wrote:
On Wed, Apr 22, 2009 at 01:14:00PM +0100, Jamie Lokier wrote:
I was more thinking of all those loadable modules. Without FDPIC-ELF
there's no dlopen() and no (useful) shared libs.
Hmm, FDPIC ELF sounds a lot more useful than FLAT. I wonder if it would
be possible
Mike Frysinger wrote:
You have to test the result of clone() before calling _exit(). How do
you guarantee the compiler inserts no memory writes in that sequence
using just INTERNAL_SYSCALL on all architectures?
there is no guarantee of course, but i declare the storage of the
return
Mike Frysinger wrote:
presumably the resolver is smart enough to not add a library to the
list until it's completely ready. especially considering the ldso
has no locking in it that i can see which means the problem would be
there regardless of forking. any thread doing dlopen(RTLD_GLOBAL)
Mike Frysinger wrote:
On Monday 06 April 2009 06:12:06 Mike Frysinger wrote:
On Saturday 28 February 2009 14:16:30 Jamie Lokier wrote:
Mike Frysinger wrote:
(like daemonizing code)
It is possible to daemonize on uClinux without exec'ing a new process,
using clone() instead
Mike Frysinger wrote:
It's easy but you need an asm wrapper for each architecture, as the
parent must not touch the stack before calling _exit.
i'm aware of this which is why i used INTERNAL_SYSCALL() rather than calling
the C library functions. those expand into the appropriate assembly
Mike Frysinger wrote:
On Saturday 28 February 2009 17:06:49 Jamie Lokier wrote:
Mike Frysinger wrote:
On Saturday 28 February 2009 14:16:30 Jamie Lokier wrote:
(I still haven't figured out if it's safe to use vfork with shared
libraries and lazy procedure lookup... doesn't apply
Lennart Sorensen wrote:
lies. there are no serious limitations at all with FDPIC ELF. it is
functionality equivalent to ELFs running under a MMU.
Well I haven't looked at FDPIC ELF since it doesn't work on m68knommu yet.
you cannot do fork() without virtual memory since both
Thomas Häberle wrote:
All used CPUs have a MMU, but it is not used due to performance
reasons as the developers state. Someone threw a number into the
discussion and said enabling the MMU would cause performance losses
of about 30-40 percent, thus if we switch to Linux at all it would
have
Michael Schnell wrote:
So, only looking at processing power is only half of the story.
Agreed !
Even there is no real technical cause for this, most non-MMU Linux
implementations seem not to support several important features needed
for doing multithreaded: TLS, NPTL, __tread keyword
Sujit Karataparambil wrote:
Is it disabled in the proprietary operating system. It is an misnomer
that MMU Slows down the embedded application.
Certainly debatable.
The key issue is do you have enough memory to turn on the MMU. Say an
4K Memory to 256M Memory the requirements are
Michael Schnell wrote:
if your arch does not support XIP, busybox in fact is loaded multiple
times. this might be a problem. That is why in my projects, I don't use
msh from busybox as default shell.
You could use sash as default shell and msh from busybox when
appropriate. See
Michael Schnell wrote:
No, it's not done like that. Linux does not provide thread-specific
virtual memory mappings, except for special cases like the
vsyscall/vdso page.
So - even with full Linux, the __thread variables have different
addresses per thread ?
Yes.
This does not make
Michael Schnell wrote:
So I don't understand why you bother about real threads at
all. some 50 Lines of C code will schedule your threads one
after the other as part of a single application/process, all running
on the same stack,
That's fine if the code is simple enough to be event driven and
Michael Schnell wrote:
It's not true at all that they use a default MMU-enabled TLS scheme
- you need arch-specific kernel support for a context switched memory
block whether it's with an MMU, or non-SMP without an MMU.
I did not look into any code for this. I was told that it should be
Gavin Lambert wrote:
It should be easy enough to get it to work with a dedicated
register, too. Just have the kernel set the register on context
switch, where it always points to a thread-specific-data table in
memory at different locations for different threads. (This would
also work for
Michael Schnell wrote:
TLS, NTPL, FUTEX, not signal based IPC, ...) Hopefully the upcoming
MMU-enabled NIOS uClinux will take care of most of this - as most is
a lot easier to do based on TLS and same is easy to do if making use
of the MMU..
That stuff doesn't depend on an MMU, really.
It's
Michael Schnell wrote:
Of course I do know, but NPTL is based on TLS and TLS is much easier
to to if you have an MMU that can provide the dedicated per-thread
memory block automatically the the system switches the MMU
configuration on a process/task switch. The MMU based implementation
seems
Jan Ringoš wrote:
Wouldn't something like this suffice?
struct shared_struct volatile * my_shared_memory = (struct shared_struct
volatile *) 0x8800;
This would have been a simpler choice, the problem is that the code has
already been written without pointers, through direct
Berkhan, Enrik (GE Infra, Oil Gas) wrote:
Andrew Morton wrote:
On Wed, 11 Mar 2009 15:30:35 +
David Howells dhowe...@redhat.com wrote:
From: Enrik Berkhan enrik.berk...@ge.com
The solution is to mark the pages dirty at the point of allocation by
the truncation code.
Was
Grant Edwards wrote:
or do the hard realtime stuff in hardware (if same can be
reduced to very simple functions).
That last qualification is an important one. When I've asked
in the NIOS forums about RTAI or other ways to control latency
on the NIOS/Linux platform, the answer is always
Robin Getz wrote:
Currently, CONFIG_UNEVICTABLE_LRU can't use on nommu machine
because nobody of vmscan folk havbe nommu machine.
Yes, it is very stupid reason. _very_ welcome to tester! :)
As always - if you (or any kernel developer) would like a noMMU machine to
test on - please
Bob Furber wrote:
( sleep 1; echo username; sleep 1; etc... ) | telnet 10.0.0.24 23
At least on my Busybox-based system, telnet cannot be used with input
from a pipe.
If you do that, it just exits with status 1 (error status).
-- Jamie
___
Bob Furber wrote:
At least on my Busybox-based system, telnet cannot be used with input
from a pipe.
Is there a way around this?
Try building netcat instead (the command is usually nc).
It's more appropriate for this job, and should build easily.
-- Jamie
Tom Stalcup wrote:
In the meantime, I collected some more information while trying this with
ftp. Maybe this will help isolate the problem.
Some functions work when piping a subshell into an FTP session, but the
printf and echo fuctions do not work properly.
( sleep 2; printf username;
Michael Schnell wrote:
If the arch supports XIP, and the executable is in an (init)RAMFS, using
a shell (e.g. msh) in busybox seems very appropriate. If it does not
support XIP, loading the big busybox executable very often is really
slow. In this case I think you can use the small sh
Mike Frysinger wrote:
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
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()
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
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
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
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,
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
Mike Frysinger wrote:
I think I can use the pipes (with their atomic writes) to get rid of any
use of mutexes in this case. But it will be otherwise a little more
complicated than just calling the exposed functions.
umm, why do you think writes are atomic ? POSIX states that read/write
Mike Frysinger wrote:
On Friday 27 February 2009 15:16:45 Lennart Sorensen wrote:
On Fri, Feb 27, 2009 at 11:17:19AM -0500, Mike Frysinger wrote:
file descriptors are not shared resources. whatever a child does with
them will not affect the parent.
I was hoping that was the case. It
1 - 100 of 200 matches
Mail list logo
