Re: [uClinux-dev] Threading and synchronization questions
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) > would trigger the same issue. If there's no locking in dlopen and it's still thread safe against ld.so resolving, I agree, it should be fine. Are you sure there's no locking? Glibc's ld-linux.so and libdl.so have some tls_ and pthread_ references. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 for Jan's ARM > > > > with no shared libraries of course). > > > > > > why wouldnt it ? there isnt any locking or such in the resolver, and it > > > isnt like there are "speculative lookups" done randomly. there is an > > > issue on Blackfin with thread safety, but that is only because we lack > > > 64bit atomic load/stores and the FDPIC PLT is a 64bit descriptor. > > > > What about when another thread is calling dlopen(RTLD_GLOBAL)? > > Doesn't that update a global list of DSOs to search? > > in a completely unrelated project, i revisited this. turns out, same exact > thing can happen with fork(). POSIX even has quite a bit of explanation on > the topic: > http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html#tag_16_402_08 > > the very last paragraph is such a nice summary: only async-signal-safe > functions are safe after a fork/vfork in a threaded environment. > > none of the dl* functions show up in that list (scroll down a page or two): > http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03 In this case, though, we're not talking about calling dl* in the child process after a fork/vfork. We're talking about calling _any_ functions which may be subject to lazy symbol resolution in the child process - that includes async-signal-safe functions like dup2(). -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
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 > different. > > When you say that the CPU has MMU, It would be wise to add memory to > the device and turn on MMU. I'd say the opposite. Often having an MMU uses _less_ memory. Part of the saving comes from easier shared libraries, demand paging, and copy-on-write fork. Part of the saving comes from greatly reduced memory fragmentation. Without an MMU fragmentation is often a problem, and can mean you need to keep 30% extra memory "free" just to be able to allocate what you need. The exact requirement depends a lot on the application. For speed, even if the CPU runs slower with an MMU, there are many speed advantages from it. Again there's copy-on-write fork. Also, the kernel is able to cache more filesystem data and things like that. OVerall if you think there MMU might have a performance penalty and you can switch it on/off - why not just try both, and see which is easier to use and which performance better for real applications doing stuff? If you have FDPIC ELF support on your architecture, FDPIC ELF executables can be run on kernels with and without MMU, so you can try the same userspace on different kernels and compare performance and memory behaviour. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
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 in C, really user > space based FUTEX. Add to that list usable shared libraries (.so) and dynamic loading (dlopen). However, this is improving all the time and they might all support those things eventually, to the point where a new architecture would be expected to support them from the beginning. Nearly all the work is in GCC and uClibc for those things. The biggest step is implementing FDPIC ELF for each architecture. It isn't all that hard, but most people are naturally a bit cautious about touching GCC and Binutils, so it doesn't happen until someone is really interested or is being paid to do that specific work. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
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 to be ucLinux. That's a very large performance loss for an MMU. It's possible depending on the implementation. Most MMUs use a TLB (which caches MMU lookups) and virtually-indexed instruction/data caches so there's little or no cost to cache hits. If the TLB is too small it might cause a significant performance loss. I have heard of a paper which says enabling the MMU on some ARM CPUs was a significant performance loss, but I've never read it. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] MMU trade-off
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 processes will have > > pointers to the same addresses and there's no way to relocate them. > > OK, I suspected that was the case. You could do what Minix does. That is to copy the process writable data and swap it on context switches - a big memcpy. That's a big performance hit, but for process which do fork-then-exec (most of them), it's only one copy, and avoids the special issues of vfork. Maybe that would be worth adding to uClinux for the convenience and portability improvement, despite the big performance hit. Then "vforkizing" packages (which is often done wrong) would be for optimisation not necessity. > > memory protection is not strictly part of the MMU. some > > processors implement MPU's (like the Blackfin processor) and the > > kernel supports it just fine. that gets you standard > > data/instruction rwx control. > > OK, I had never heard of it done that way before. That's neat. > Certainly not typical of a nommu system though. Fwiw, there are m68k systems which implement a similar no-mmu protection scheme. I played with one around, oh, 1989 or so :-) I don't know if any still do this and run Linux. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] small but powerful init and shell processes
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 http://www.nioswiki.com/Initialization_Script You can build busybox with just 'msh' and 'test' configured, no other applets, then it's much smaller. If you have XIP, there is still a significant reduction from doing this, because the data section is much smaller. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 always returns to your event scheduler. But some code looks like spaghetti that way, and then it's better to use scheduling points inside functions, rather than having to return from the whole function stack after recording local state into a state structure. Of course you can still do that without a kernel :-) For more complex real-time stuff, often you have priorities, locking between threads, and priority inheritance to avoid priority inversion. The simple event-driven loop gets complicated with priorities, when one event handler needs to interrupt another event handler in the middle. The loop starts to resemble a full blown kernel scheduler... -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 sense to me Because you haven't thought it through. You are allowed to take the address of a __thread variable in one thread, and access that specific instance from another thread, so long as the first thread has not terminated. > as there is an MMU that would make accessing these variable on a > single address possible Also doing it through the MMU would be slower. Count the TLB flushes. There are some circumstances in which the MMU version would be faster. Dynamically loaded libraries containing __thread variables do some indirection to access them, and virtual memory might reduce or eliminate the indirection. But other things would be slower. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 userspace threads.) Of course, the compiler would > have to be convinced to leave that register alone, similar to how it > already behaves with the stack pointer and frame pointer registers. Registers (that GCC would have to leave alone) are automatically updated on context switch. That's what a context switch does :-) No kernel changes are needed, if the register is an ordinary one which you are telling GCC to leave alone. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 easy > and not (largely) arch specific to do TLS if you have an MMU and thus I > _supposed_ that an MMU region would be used for TLS which is different > per thread while the other memory is not. This seems quite logical to > me: having the TLS for each thread at the same virtual address and do > the switching in the same way as the process memory is switched (thus > quite "out of the box" and not arch specific). 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. Some arches have a page which is per-thread, called the vsyscall/vdso kernel page. User-space calls routines in that page. In that page, a pointer to the TLS area might be stored, swapped on context switch by the kernel, and retrieved by calling a routine at a fixed address in the page. The details are always architecture specific, and many archs with MMU use a dedicated register for TLS because it's faster and simpler. ARM Linux uses both techniques, depending on the architecture revision. On no-MMU architectures, the "swap on context switch" method with vdso kernel page can still be used, but generally it isn't because NPTL TLS is implemented alongside ELF DSO support, and that's always been done so far using a dedicated register on no-MMU architectures (FDPIC). It is easier to get the vdso method working with an MMU, I agree. > >Maybe not slower, but larger, surely? > > I suppose so, but nowadays, memory is not a real issue any more... :-) . It is on some embedded systems. But I've forgotton what we were talking about :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 to be available "out of the box" as soon as an MMU-enabled
> Kernel is compiled, while a not MMU based TLS implementation needs
> arch- and compiler- depending code (e.g a processor register can be
> reserved as TLS pointer or a dedicated variable can be used that is
> updated with any process/task switch.
Most arches with MMU use a dedicated register or something like that.
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.
> That is why the compiler team usually seems only to care for
> implementing the "__thread" keyword for processors that do have an MMU.
I think it's because they and the kernel team are only interested in
processors with an MMU, and they assume support for those without can
be added by someone else, later.
Also, I think it's because GNU-TLS really depends on ELF and
dynamically loaded libraries - which most no-MMU toolchains don't
support (but some do).
> NIOS only got an MMU recently, so we need to wait for the next
> compiler (gcc 4, about to be released right now) for TLS
> support. With that it would be possible to do TLS (and thus NPTL)
> for MMU-less NIOS systems as well, but I doubt that anybody will
> care, as - other than what I expected - when done in the same FPGA,
> the NIOS with MMU is not (much) slower ("fmax") than the NIOS without.
Maybe not slower, but larger, surely?
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 just that historically, NPTL has been ported to architectures with an MMU first. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may get wrongly discarded
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 send me a private email. Well, that explains why vmscan has historically performed a little dubiously on small nommu machines! By the way, this is just a random side thought... nommu kernels work just fine in emulators :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: uCLinux and RTAI
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 "do it in > hardware!". That's fine if you have to toggle pin B whenever > pin A changes, but for things like replying to a message on a > TCP connection such advice is utterly useless. I'm surprised nobody has mentioned the real-time Linux patches :-) Specifically the PREEMPT_RT tree. The advantage of their method is that RT processes have access to all the normal Linux features - in kernel space and userspace. You lose the RT aspect temporarily while you do something that you couldn't expect to be RT anyway, like read a file, or a pipe waiting for a non-RT process, but at least you can do those things when its useful, and get RT properties when you're not doing such things. With network prioritisation and the experimental process-context TCP stack (which is not in the kernel), you might realistically be able to reply to a message over TCP with RT timing. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] RE: [PATCH] NOMMU: Pages allocated to a ramfs inode's pagecache may get wrongly discarded
Berkhan, Enrik (GE Infra, Oil & Gas) wrote: > Andrew Morton wrote: > > On Wed, 11 Mar 2009 15:30:35 + > > David Howells wrote: > >> From: Enrik Berkhan > >> > >> The solution is to mark the pages dirty at the point of allocation by > >> the truncation code. > > > > Was there a specific reason for using the low-level SetPageDirty()? > > No, no specific reason. It was just my first try of a fix after spotting > the problem. After a short discussion with David, we decided to wait for > others' comments on using the low-/high-level approach. Tangentially related... Does the vm pageout logic include or skip these "dirty" pages looking for candidates to flush to storage? What about with MMU? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Using absolute symbols in a bFLT binary
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 structures access, > >because it is a bit faster and smaller. > > In C++ you could use a reference :-) Otherwise, I don't see any other way. Do this: #define my_shared_memory (* (volatile struct shared_struct *) 0x8800) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] ( subshell ) | telnet--> not workingon WildFireucLinux
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"; sleep 2; printf "pwd" ) | ftp 10.0.0.24 > > This will connect to the FTP server, which will query for the username, > then afer a 2 second delay, apparently send a carriage return, delay again, > and get stuck waiting for a password. So sleep works, but the two printf's > are sent together as a single carriage return after the first delay. > > ( sleep 2; echo "username"; sleep 2; echo "pwd" ) | ftp 10.0.0.24 > > Same behavior as the printf method, except that a single carriage return is > sent BEFORE the initial 2 second delay. The sreen is shown waiting for a > password, like in the first example above. If you're using a no-MMU architecture, you may get better results with sh -c 'sleep 2; echo "username"; sleep 2; echo "pwd"' | ftp 10.0.0.24 (for example). -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] ( subshell ) | telnet --> not workingon WildFireucLinux
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 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] ( subshell ) | telnet --> not workingon WildFireucLinux
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 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] A shell with functions?
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 (which features a > lot builtin commands) as the shell to be started by init, and if you > need more complex scripts same can start a file that is interpreted by > msh. See e.g.: http://www.nioswiki.com/Initialization_Script Even with XIP, it's a good idea to compile a separate Busybox with just the shell enabled, and use that for the shell. XIP saves the code duplication, but the writable data space is still duplicated for every executable and can be quite large with a fully configured Busybox. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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. Daemonizing seems quite common, > > > so I would have expected to find it in glibc or such. > > > > There is a function in glibc. Try "man daemon" :-) > > The only trouble is it's not (yet) found in uClibc for no-MMU archs. > > > > I don't know what happened to the version I posted to the Busybox > > bugzilla. Searching on the Busybox bugzilla yields no results. > > when did you post it ? the mantis bug tracker was dropped recently and none > of the old bugs were moved over to the new bugzilla ... It was a couple of years ago. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 hold for
> most non-MMU-systems.)
(The common name is "atomic" not "monolithic" :-)
For non-SMP systems without useful atomic ops, the best option might
be what ARM does. There's a routine __kernel_cmpxchg ("atomic compare
and exchange") at a fixed address in memory. All other atomic ops must
call that routine.
The kernel scheduler checks the instruction pointer on every interrupt
and kernel entry. If the instruction pointer is inside
__kernel_cmpxchg, after the load and before the store, the interrupt
adjusts it to make __kernel_cmpxchg start again.
That makes it atomic without disabling interrupts. (Which I don't
think you can do on ARM no-MMU in userspace anyway).
You could copy that method for your architecture, if you don't want to
add atomic instructions to your FPGA :-)
However, since you have an FPGA, load-locked/store-conditional atomic
sequences are probably easy instructions to add _if_ you have only one
CPU. You'd just implement a store-guard flag which is cleared
whenever an interrupt or trap occurs - trivial :-)
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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. There is a function in glibc. Try "man daemon" :-) The only trouble is it's not (yet) found in uClibc for no-MMU archs. I don't know what happened to the version I posted to the Busybox bugzilla. Searching on the Busybox bugzilla yields no results. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 based on Futex. But now I find: no Futex, no fast way > to get a thread ID. Quite frustrating) Actually you can use raw futexes if you're prepared to write your own mutexe. That doesn't use any thread library. It's just a system call. It's how futex was used originally, and it's still used that way for some things. You might be able to copy the NPTL mutex code, rename the functions and use it in your own program - maybe from an older version, which doesn't need the kernel to support futex atomic ops. (Those were added later as an optimisation). Before jumping to conclusions about speed, try measuring the speed of pthread_getspecific and pthread_self. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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, depending on the toolchain options and ARM generation. > > Is there any other way to have a unique thread ID that the thread can > > _easily_and_fast_ access ? > > there is probably always a way to hack something together, but TLS > is the only "portable" solution. TLS isn't remotely portable. Notice how we're discussing uClinux and some currently maintained uClinux targets don't have TLS :-) pthread_getspecific is much more portable. But not as fast. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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, ...) LinuxThreads uses signals. Signals are clunky but the other things have different problems. > > - Futex-based primitives mean mutexes and other synchronisation > >between threads are much faster. > > > Maybe Futex is implemented using TLS (I understand that it can be done > that way), so I do see that Futex depends in TLS, but TLS has nothing to do with Futex. > I still don't see why TLS depends on NTPL, Why should implementing > TLS with "Linux Threads" should not be possible ? 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. > > - You can have inter-process (system-wide) mutexes and other > >synchronisation objects in shared memory. > > > Why does this depend on NPTL ? I understand can request shared memory > and use Mutex without using threads. You can't have pthread_mutex_t without using pthreads :-) Are you thinking of a different kind of mutex? You can't just put a pthread_mutex_t in shared memory. It won't work properly. > And if I create a thread why should > same not access the shared memory mapped to it's process or use a Mutex > it's process created - with or without NTPL and with or without MMU ? Yes, of course you can access shared memory mapped into multiple processes on any of those combinations. That's the best way to share memory. You can't expect mutexes shard between processes to work though, unless you specifically request a system-scope mutex, which LinuxThreads doesn't support. > > - Actually POSIX correct behaviour. E.g. getpid() returns > >the same value for each thread. Signals are delivered in the way > >described by POSIX. Etc. So more code just works with NPTL. > > > AFAIK, there is a scheduling issue, regarding assigning time slices to > threads with respect to the other running processes, too. That's fine tuning and not always important. There's no "correct" time slicing anyway. Compare with putting mutexes in shared memory on LinuxThreads, which is simply broken. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 fast call to a very short function provided by the kernel. > When I was thinking about the multithreaded application I am planning, I > found that I need a thread to know some unique ID. (I'll have multiple > threads that use the same code, so sometime they need to know which one > they are.). > > I see that this can be done with TLS. > Do you suggest that TLS is not available in a uCLinux system ? It's available on some uClinux systems. You can add support to yours, be my guest :-) > Is there any other way to have a unique thread ID that the thread can > _easily_and_fast_ access ? If you have a small number of threads, pthread_self() with LinuxThreads is ok. It searches a linear array to find which stack contains the current stack pointer. If you need it to be really fast and you don't have an MMU, you have to dedicate a register to holding something unique about each thread - either an id, or a pointer to a structure. That's what TLS does on many architectures. You can do itself if you're willing to recompile _everything_ (including libc etc.) telling GCC about the extra register, but that's usually a bad idea. With an MMU it's possible to store different values at the same address in each thread. TLS on some architectures works like that. With LinuxThreads you can use the portable pthreads method: pthread_getspecific(). It's not as fast as TLS, but not slow either. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 really see the big advantage over old Linux threads, > but of course it is nice to provide the most recent stuff... TLS "Thread Local Storage" is the ability to say int __thread i; And get a variable which is different in each thread, and fast to access. You can get a similar effect with standard pthreads and using macros for every access, but this is better and faster when available. NPTL's advantages over LinuxThreads which come to mind: - Faster to create and destroy threads. - No "manager" extra thread memory overhead. - Faster to communicate between threads because it doesn't use signals. - Futex-based primitives mean mutexes and other synchronisation between threads are much faster. - You can have inter-process (system-wide) mutexes and other synchronisation objects in shared memory. - Actually POSIX correct behaviour. E.g. getpid() returns the same value for each thread. Signals are delivered in the way described by POSIX. Etc. So more code just works with NPTL. - Stopping the whole process with SIGSTOP works properly, and killing it with SIGKILL works properly. - ps and top show one process, not lots of processes. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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() in the child process. You should call _exit() instead. You should normally call _exit() in a child process created with fork() too, but there are plenty of exceptions. Think about what happens to stdio buffers, atexit() registered functions, and global destructor functions (think C++), when you call exit(). -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 ) well defined or is it > depending on the arch (MMU or MMU-less) ? clone() is dependent on the arch in lots of ways. vfork() doesn't just call clone(), because the way the child and parent process share the same stack complicates it. 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. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 execvp() and execlp(), which is to say the least risky. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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, why not continue to use vfork() ? Or do
> these archs just map vfork() to fork() and thus ignore the
> vfork-specialties (e.g. that the parent is blocked until the child does
> *exec() or *exit() ) ?
If you're sticking just with uClinux, it's quite predictable. If your
code might encounter Linux in its more general usages (LD_PRELOAD,
etc.) than you should be careful. If you're considering portability on
other OSes, you have to be even more careful.
- Some platforms map vfork -> fork.
This includes old versions of Linux.
But if your code is sensible, this doesn't matter.
- Don't write to variables in the child process for the parent to read.
This doesn't work if vfork is mapped to fork, obviously.
- Calling open/close/dup/dup2 in a vfork'd child process (before execve)
is normally fine. But if your process is running with some
LD_PRELOAD file tracing library which interposes those functions
and the parent process is using threads, it can break. There's
quite a few such libraries.
- Some LD_PRELOAD libraries map vfork -> fork for various reasons.
One reason is to make file tracing work (previous item). Another
reason is to make some debuggers work.
- Calling open/close/dup/dup2 also fails if your program is
linked with some "userspace virtual filesystem" libraries.
- On Linux and nearly all OSes, the child has separate file
descriptors from the parent, so open/close/dup/dup2 are ok. This
is normal because vfork is nearly useless without it. But on
some OSes (possibly just old ones), the child and parent share
file descriptors.
- On Linux and nearly all OSes, you can set a signal handler to
SIG_IGN or SIG_DFL in the child process which is useful before
exec. This isn't portable: on some other OSes, changing a signal
handler affects the parent process too.
- According to POSIX, the _only_ system functions a vfork child
process may call safely are the exec family of functions and
_exit. But this is nearly useless in practice, and real
systems are not so restrictive.
- It is important that _exit is used in the child, not exit.
(This is usually right with fork too).
- 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 functions; must not even modify _local_ variables in
the function which calls vfork (with specific exceptions), and
must not call functions which affect global memory state (except
intentionally).
- Ironically, some implementations of exec functions which search a
path call malloc, so may be unsafe. So in portable code, only
use execve or execv, and do path searching yourself if
required, without calling malloc.
- Optimising compilers place local variables on the stack in ways
you might not expect, including using the same part of stack for
different variables whose uses appear to not overlap. This is
why it's important for the child code not to write to most local
variables - the compiler may optimise those stores to overwrite
other parts of the stack. With GCC and Linux this is not likely
to be a problem because GCC knows to treat vfork specially, but
on some other OSes you have to be more careful. I avoid these
issues for the most part by calling a separate function for the
child actions prior to exec.
In my code, which I admit tries to be very portable to many OSes and
compilers, if I use vfork it's structured rather like the attached
snippet.
Enjoy :-)
-- Jamie
static int do_vfork(struct child_args *args)
__attribute__((__noinline__));
static void child_actions(struct child_args *args)
__attribute__((__noinline__, __noreturn__));
int
start_child_process(char *path, char **argv, char **envp);
{
struct child_args args;
memset(&args, 0, sizeof(args));
args.path = path;
args.argv = args;
args.envp = envp;
return do_vfork(&args);
};
static int
do_vfork(struct child_args *args)
{
pid_t pid = vfork();
if (pid == 0)
child_actions(args);
/* Parent stuff. */
...
}
static void
child_actions(struct child_args *args)
{
/* Child stuff. */
int error_code;
... dup2/close etc.
.. setsid if needed, setpgrp if needed, fchdir if needed etc.
.. sigaction/signal if needed.
execve(args->path, args->argv, args->envp);
if (args->error_pipe >= 0) {
error_code = errno;
write(args->error_pipe, &error_code, sizeof
Re: [uClinux-dev] Threading and synchronization questions
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 for Jan's ARM > > with no shared libraries of course). > > why wouldnt it ? there isnt any locking or such in the resolver, and it isnt > like there are "speculative lookups" done randomly. there is an issue on > Blackfin with thread safety, but that is only because we lack 64bit atomic > load/stores and the FDPIC PLT is a 64bit descriptor. What about when another thread is calling dlopen(RTLD_GLOBAL)? Doesn't that update a global list of DSOs to search? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Mike Frysinger wrote: > 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 ... futex mutexes should be easy. The harder bit is TLS. Switching to NPTL implies both, as far as I know. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Mike Frysinger wrote: > On Saturday 28 February 2009 13:58:04 Jamie Lokier wrote: > > 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 > > > functions need not be atomic. if you want threading synchronization > > > mechanisms, then use the things designed for exactly that. > > > > Pipes are special, and Jan _can_ rely on writes <= PIPE_BUF bytes > > being atomic. This is a POSIX requirement and Linux meets it. > > > > From the Linux man page for pipe(2): > > > >PIPE_BUF > >POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes > >must be atomic: the output data is written to the pipe as a > >contiguous sequence. Writes of more than PIPE_BUF bytes may be > >non-atomic: the kernel may interleave the data with data > >written by other processes. POSIX.1-2001 requires PIPE_BUF to > >be at least 512 bytes. (On Linux, PIPE_BUF is 4096 bytes.) > > > > It makes no difference if the pipe is between processes or threads, or > > even from a thread to itself. Writes <= PIPE_BUF in size are atomic: > > they are either written whole, or block, or return EAGAIN if non-blocking. > > > > Writes > PIPE_BUF in size are not atomic, and can be split up at any > > position. > > taking a snippet from the spec and removing key words doesnt make the result > correct ;). in the actual link to POSIX that i posted, it clearly uses the > word "processes" everywhere. Good catch. Nonetheless, it is atomic between threads on Linux, and documentation for AIX and IRIX says it is explicitly on those. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does anyone have m68knommu running with current uClibc and gcc 4.3?
Lennart Sorensen wrote: > > You will need to disassemble a simple program and see what code is > > generated. Look for differences on the same code compiled with the > > older toolchain and the newer. > > Yeah, although of course if it is the ABI change I am not sure how I would > recognize something calling a C function incorrectly in the assembly. It's probably easier to look at the GCC source itself, look at what oldabi sets differently. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Michael Schnell wrote: > > >4) Can pthread mutexes be used across vfork/exec sub-processes? > >In documentation to pthreads they say that the pthread_mutex can be > >used to synchronize threads but not processes. But I see no difference > >between thread and process in uClinux. What am I missing? > To do threads you should use the pthread library. So you don't bother > about (v)fork-ing the threads. pthreadlib also provides the thread-mutex > methods and supposedly will use FUTEX (fast user space Mutex) instead of > mutex, which is a lot faster if the architecture provides appropriate > support. It only uses FUTEX if the pthread library is NPTL, and I don't think that's available for ARM no-MMU at the moment. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Michael Schnell wrote: > > >9) Or is my approach of multiple processes otherwise flawed? > In Linux the communication between processes is really fast, cheap, easy > and versatile. > > You can e.g. use pipes/queues (e.g. named pipes in the file system or > system 5 message queues). > > In many cases you don't need threads to wait for data from such a queue > as you can use appropriate system library calls like "select()" or (the > new, more advanced way) (e)poll() (which despite of it's name does not > do any actively spinning polling) to schedule your reactions on several > events thrown by other processes. In Linux "everything is a file", so > handling such queues (and IP-sockets, hardware ports etc) is done using > the same paradigm as with handling normal files. It's usually not as cheap as threads because you have to design and implement a protocol for every little thing that's communicated. That takes time, and it also uses more code space. But it's far cleaner and easier to debug separate processes. And as Jan noticed, if you want to install just the components you need for different configurations, that's easier with separate processes than a single giant application. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Jan Ringoš wrote:
> 1) If properly synchronized I can access data of other processes.
Yes, but only if you don't use certain GCC compile options (-fPIC etc.)
> 2) Is atomic write to a pipes up to PIPE_BUF guaranteed on uClinux?
Yes. See "man pipe".
> 3) There is no practical distinction between process and thread in uClinux
> as there is in Windows world.
Yes there is. uClinux behaves the same as ordinary Linux. There are
processes, and inside each process there can be multiple threads.
> 4) Can pthread mutexes be used across vfork/exec sub-processes?
No. It won't work. It might _look_ like it works - because it can
access memory in a different process without checking - but the
synchronisation won't be reliable.
Linux's pthread knows the difference between threads and processes.
In each process, it keeps a list of threads for that process, and
mutexes use that list.
> In documentation to pthreads they say that the pthread_mutex can be used to
> synchronize threads but not processes. But I see no difference between
> thread and process in uClinux. What am I missing?
Threads and processes are quite different.
> 5) There is no dynamicaly-loaded-library (DLL, or .so, or whatever) support.
The Linux name is DSO (dynamic shared object). Yet another name :-)
It depends on the architecture. Some uClinux architectures have them.
ARM no-MMU doesn't, but I have done some work on ARM FDPIC-ELF to add
support for DSOs.
> 6) Vfork does not copy any data/code from the old process to the new one,
> or does it? The real question is, will some pointer carried to the new
> process always point to a data in the old process.
You should be careful with vfork. It's best avoided because it's
difficult to use safely, but on uClinux you don't have a choice.
Only do a few necessary things which are basic system calls, such as
call dup/dup2/close/chdir, then call execve or _exit. Don't call
functions like printf or malloc, or exit.
In the vfork child process, you can access the parent's data but you
should not write to it. This includes local variables in the function
which calls vfork which the parent might use after! To be safe, you
can just call another function: if ((pid = vfork()) == 0)
child_function(); and never return from child_function, call _exit().
There are many other rules about safe vfork usage. Keep it simple.
> 7) For data variety, I decided to use a SQLite database. In my current
> design, there will be more separate processes running and using the
> database. But the footprint of the SQLite is relatively large. Provided
> that my code will comply to the threading limitations documented by SQLite,
> can I have it loaded just in single core process, and accessed by other
> processes? SQLite uses pthreads for synchronization.
SQLite is a good library. But doing that isn't safe. See above:
pthread mutexes won't synchronise reliably.
It's better to rely on SQLite's normal method of file locking, and
loading the library into separate processes.
> 8) If pthread_mutex cannot be used across processes, is there an
> alternative?
You can use SYSV semaphores ("man semget"), and you can use sockets
and pipes with a protocol of course. You can also use file locking:
fcntl(F_SETLKW). SQLite uses file locking.
POSIX semaphores ("man sem_overview") are not available between
processes on Linux 2.4. On Linux 2.6, they're not available on ARM
no-MMU yet because of the threading library. (And *if* you had
working POSIX semaphores, you could create special process-wide
pthread mutexes too.)
> 9) Or is my approach of multiple processes otherwise flawed? My intension
> is to minimize memory and disk footprint by including only components
> necessary for particular application. Have I other option than to write big
> monolithic process?
Sometimes you can reduce the footprint using XIP to share code of an
executable in multiple processes. This can make a lot of difference
if you have, say, many Busybox processes running different commands.
The best way to reduce footprint (without a monolithic process) is
shared libraries, and that's not available on ARM no-MMU yet. I have
done some work on it (ARM FDPIC), but it's stopped for now.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
Jan Ringoš wrote: > From: "Gavin Lambert" > >Quoth Jan Ringoš: > >>3) There is no practical distinction between process and thread in > >>uClinux > >>as there is in Windows world. > > > >Untrue. Just as on Windows, processes have separate address spaces > >(normally) while threads > >have shared address spaces, and threads are owned by processes. The main > >distinction between > >Windows and Linux in this regard is that processes are significantly > >cheaper to create in Linux > >than under Windows, but processes are still heavier than threads. > > Well, I am interested in uClinux only, in this case. I still don't see the > difference. If all the processes live in the same address space here, and > when I create a thread (pthread_create) I see a new duplicate process > through ps command (just as if created by vfork), then what can it be, that > would make pthread_mutex not work? On uClinux, processes don't live in the same address space logically. It _looks_ like one address space because there's no protection or remapping - often you can access memory of a different process using a pointer from the other process. But if you look closer, there's more to an "address" than the 32 bits of a pointer. Pointers are sometimes deferenced with a process context, in the form of XIP/PIC registers or the TLS register. That means you can't _always_ use pointers from another process. This is clear when code is compiled with XIP - which you can do on ARM too. It's also more obvious with FDPIC-ELF. > I am sorry, maybe I am little slow here. Feel free to stop me if I am > challenging some immutable truth :-) I do recall reading something about > changes from kernel 2.4 to 2.6. I am not sure what it was exactly, but I > should get my hands on 2.6 kernel version of the device soon. The kernel doesn't make any difference to your questions. 2.4 to 2.6 does make a lot of difference to other things, though :-) Use 2.6 if you can, it's much better in most ways. However, there are some problems with no-MMU memory fragmentation (reported here recently) which haven't been fixed in 2.6 yet. > 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. If you just call the exposed functions, you'll have all sorts of problems when you port your code to another platform - including the same chip with different GCC options. It's a bad idea, even though it's easy. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 did seem like vfork + exac would > > loose a lot of purpose if file descriptors weren't duplicated by vfork. > > yeah, it would make redirecting of std* fd's real painful (like > daemonizing code). i didnt think vforked children having their own > fd's would work under no-mmu until i thought about it a bit more. > the fd indirection with the kernel can be thought of a little like a > mmu: the real resources are translated to per-process identifiers. You have to be very careful with vfork. Lots of things don't work reliably and are dangerous, even if they work most of the time. Also, code which depends on vfork behaviour isn't portable except for a few things which are allowed. On Linux, you can safely call most system calls in a vfork child: - Change file descriptors with open/dup/dup2/close. - Use fcntl F_SETFD to change the close-on-exec flag. - Change directory with chdir/fchdir. - setsid/setpgid etc. to manipulate terminal sessions. - setreuid etc. to manipulate user ids for setuid processes. - Change signal mask and signal handlers to SIG_IGN/SIG_DFL. You should not do _anything_ with threads in a vfork child. pthread_self() is not safe. Thread-local variables are not safe to acccess. (I still haven't figured out if it's safe to use vfork with shared libraries and lazy procedure lookup... doesn't apply for Jan's ARM with no shared libraries of course). > (like daemonizing code) 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. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Threading and synchronization questions
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 > functions need not be atomic. if you want threading synchronization > mechanisms, then use the things designed for exactly that. Pipes are special, and Jan _can_ rely on writes <= PIPE_BUF bytes being atomic. This is a POSIX requirement and Linux meets it. >From the Linux man page for pipe(2): PIPE_BUF POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be non-atomic: the kernel may interleave the data with data written by other processes. POSIX.1-2001 requires PIPE_BUF to be at least 512 bytes. (On Linux, PIPE_BUF is 4096 bytes.) It makes no difference if the pipe is between processes or threads, or even from a thread to itself. Writes <= PIPE_BUF in size are atomic: they are either written whole, or block, or return EAGAIN if non-blocking. Writes > PIPE_BUF in size are not atomic, and can be split up at any position. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Signals sometimes not delivered (m68knommu)?
Mike Frysinger wrote: > > SigBlk: 01e847a881d8f42a > > maybe it's me, but that looks like garbage Me too. I'm too lazy to check the lower 32 bits, but no program has such a bit pattern in the upper 32 signals. > > I have searched around and cant seem to find any code obvious that is > > doing this. Any suggestions on where I shoudl be looking? > > when we had a similar issue under Blackfin/uClibc, our sigjmp related code > wasnt entirely correct and would sometimes restore garbage in the signal mask > > otherwise, your best bet is probably to try and get a simple test case (in C) > which you can hook up with gdb and step through in leaps while monitoring the > status file. once it gets corrupted, you can narrow it down further. > > or perhaps run things through strace and maybe someone is calling > sigprocmask() incorrectly on you All good suggestions. I vaguely recall some m68k structure padding/alignment issues with either standard or sigingo signal stack frames. If there's a mismatch between the kernel and whatever uClibc is expecting, or even what the application is expecting if it fiddles with signal contexts, that might corrupt the signal mask. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] question
Mike Frysinger wrote: > On Wednesday 25 February 2009 07:14:30 angelo wrote: > > i am wandering if i am writing in the correct list, since i written many > > mails but i never had an answer. Maybe the "develoment" mean a branch > > for the uclinux dist. developers team only, or maybe custom hardware > > related questions are not welcome ? > > this is the only list for the uClinux patchset and distribution (i.e. > uclinux.org), and similar (but not restricted to) common no-mmu issues. > > people answer questions as they feel like it. if no one is answering your > questions, well i guess no one felt like it. Maybe angelo's question would take a lot of background work to answer it, so nobody felt like doing it. angelo, custom hardware questions are welcome here, but it's a matter of luck of there's somebody who knows about it. Sometimes you just have to try asking to found out. With no answer, it's worth looking for another list which deals specifically with your particular hardware or applications. If you get no answers anywhere and it's important to you, the choices are figure it out yourself from the code, or there's plenty of professional uclinux consultants around... :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > > >No doubt VM tunables can be adjusted in 2.6 to > >release that page cache faster, but the defaults aren't fast enough. > > > That is why I suppose using 2.6 is the way to go here. 2.6 has a large number of very good reasons to use it, but it does seem to have regressed w.r.t. fragmentation avoidance on no-MMU, which might be a showstopper. It's not clear that tweaking VM tunables is enough - new code may be needed. The 2.4 code works, but to be fair it's got many problems too - and I'm in the interesting position of having to find/write a fix for a client, either using 2.4 or 2.6, whichever works. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > >In my particular case kernel uses all available >RAM (~10MB) for disk >cache and releases it only in ~15 seconds. Other >applications cannot > Andrei's filling page cache at the rate of ~10MB in 15 seconds. > Hmm. I understood the 10 MB were allocated as cache in whatever time span and > only released after a hold-off of 15 secs. (But I'm not a native English > speaker :) ) Pages allocated more than 15 seconds ago would be released by the VM since that's how long it takes to release them isn't it? :-) But don't assume I know exactly what I'm talking about here... :-) To be honest, I did jump to a conclusion that Andrei's observation is due to streaming data from disk at video rates (which 10MB/15sec is), since I've often encountered that problem, and I'm working on similar hardware to Andrei (not quite the same) which is primarily an MMUless platform for video playback. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > > >Certainly, on 2.4, you cannot find suitable settings in a standard 2.4 > >kernel. Only the patched uClinux 2.4 kernel works, and I had to patch > >it some more. > > > I suppose v2.6 offers more on that behalf. It does, but the page_alloc2.c allocator option in 2.4 seems to be absent in 2.6. A cursory look suggests 2.6 has no equivalent functionality, but I stress the "cursory" :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > I understand the Andrei sees the problem in any case, not only with high > rate traffic. Andrei wrote: >> In my particular case kernel uses all available RAM (~10MB) for disk >> cache and releases it only in ~15 seconds. Other applications cannot Andrei's filling page cache at the rate of ~10MB in 15 seconds. That's what I mean by streaming at a relatively high rate for these sort of devices. No doubt VM tunables can be adjusted in 2.6 to release that page cache faster, but the defaults aren't fast enough. On 2.4.26, I've had similar problems where you have to adjust the "how fast to evict clean page cache" tunable according to which application is running. Too fast eviction and you can't stream video at 1MB/second without stalling. Too slow eviction and it fills up and fragments, which page reclamation isn't good enough to solve. On 2.6 I'd hoped the new VM would adjust the tunable automatically but it sounds, from Andrei's words, that this isn't true in 2.6.24. Some interesting defragmentation heuristics went in since 2.6.24, which is why I suggested he try 2.6.28, but the problem of no-MMU ARM not working in 2.6.28 stopped that. That last thing is why I wonder if there's really anyone using no-MMU ARMs with 2.6 kernels much. Maybe they're all using 2.4, and 2.6 users prefer to target more capable chips? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Andrei Martynov wrote: > Thursday, February 19, 2009, 8:57:46 PM, Jamie Lokier wrote: > > > 2.4.37 is a bit better because it has some USB storage bug fixes and > > things like that. > > I've just found an old thread about different memory allocator > behavior in 2.4.17 and 2.4.24 that results in memory fragmentation > during system boot. How is it in 2.4.37? > > Mail list archives are not available at the moment so I had to attach > the original mail. I'm not awaye of any significant differences in the allocators from 2.4.17, 2.4.24 or 2.4.37. The email you attached says that fragmentation got worse (from 2.4.17 to 2.4.24), but the response says the only change was putting small blocks at the start and large ones at the end, instead of the other way around. I don't see how that would make a difference to fragmentation. Perhaps the questioner made some other changes, like changing the default allocator? Perhaps VM tuning parameters were changed - that makes a difference depending on workload. I haven't tried 2.4.37, only 2.4.26. I wouldn't expect a big change in behaviour, but the only way to be sure is try it. - Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > > >I'm surprised after all the effort to merge NOMMU into 2.6 as a > >standard feature that it doesn't work as well as 2.4 kernels. > > > > If this would be true no MMU-less devices with 2.6 Kernels would work > properly. But I understand that there are millions of them sold ... I'm aware of zero MMU-less devices with a 2.6 kernel which are streaming files at video rates from local storage. Whereas there are millions of such devices running a 2.4 kernel. If you know of _any_ MMU-less device with a 2.6 kernel which streams video files from hard disk, or similar streamed filesystem workload, I and Andrei would be _very_ interested to look at the kernel code. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Michael Schnell wrote: > >In my particular case kernel uses all available RAM (~10MB) for disk > >cache and releases it only in ~15 seconds. Other applications cannot > >be started if one reads large files from disk. I do not experience > >this problem with 2.4.17 kernel. > > > AFAIK, the Kernel _should_ reduce the disk cache as soon as memory is > needed for other purposes (e.g. starting an application). Of course this > might take some time for writing back the uncommitted blocks, but of > course _much_ less than 15 seconds. It's all clean data; there is nothing to write back. It's a common misconception that "free space is wasted space", so it's ok to fill all the memory with clean page cache. It comes from the fact that actually it _is_ good with an MMU, but causes insurmountable fragmentation problems without an MMU. > AFAIK, there are several settable (maybe when compiling, maybe at run > time) parameters that define the disk cache behavior. Did you take a > look at those ? Certainly, on 2.4, you cannot find suitable settings in a standard 2.4 kernel. Only the patched uClinux 2.4 kernel works, and I had to patch it some more. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Jamie Lokier wrote: > Is this for the Sigma Designs ARMs? The latest they've used is > 2.6.26-uc0, however looking at the changes in 2.4 kernels, the most ^^ > recent 2.4.37 kernel should work as well. Sorry, I meant 2.4.26-uc0, not 2.6.26-uc0 :-) 2.4.37 is a bit better because it has some USB storage bug fixes and things like that. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Most stable 2.4.x kernel for ARM
Andrei Martynov wrote: > what 2.4.x kernel ( > 2.4.17 ) can be recommended for ARM NOMMU > target? I cannot solve problems with memory fragmentation in 2.6 > kernel and want to step back. That's a disappointing result. If problems cannot be solved on ARM NOMMU, then it's very likely they cannot be solved on any NOMMU architecture. Is this for the Sigma Designs ARMs? The latest they've used is 2.6.26-uc0, however looking at the changes in 2.4 kernels, the most recent 2.4.37 kernel should work as well. The difference in memory handling between 2.4 and 2.6 kernels is enormous, but the difference from 2.4.17 to 2.4.37 is not much, especially in the memory allocator and reclamation. I'm surprised after all the effort to merge NOMMU into 2.6 as a standard feature that it doesn't work as well as 2.4 kernels. Is this because most uClinux major contributors target architectures with MMU nowadays, so NOMMU support isn't important to them any more? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] howto generate Kconfig files from Config.in for busybox
Michael Schnell wrote: > (adding support for MMU, so, PIC, and XIP). You don't need an MMU for PIC or XIP. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Build SMP uClinux on NIOS II processors
Michael Schnell wrote: > >I would like to have an SMP uClinux running on the multilple NIOS II > >processors architecture (with or without cache coherence). > You might want to discuss this on the NIOS2 uCLinux mailing list: > nios2-...@sopc.et.ntust.edu.tw . > > Did you already solve the appropriate hardware issues ? > > I suppose you _can_ add multiples NIOS processors to the Avalon bus > using the SOPC-Builder. > > But for SMP they would need to access a common memory and here you need > to take care of cache consistence. AFAIK, this is not supported at all > with the current NIOS Altera ip Core. So you would need to switch off > the data cache completely, resulting in a very slow system. Maybe on top > of this, you can do a cache design of your own in HDLC: either a common > stack for both processors (quite slow due to the need for scheduling the > requests) or a stack for either of them with additional hardware to > invalidate the cache lines that are written by the other processor and > to force writing of the cache lines read by the other processing similar>. You can tell Linux to explicitly flush cache lines, so that you don't need consistency in hardware. You only need cache line flushing instructions, which is simpler hardware. You need those instructions anyway if you have peripherals doing DMA to main memory, so you might not need any changes to the hardware cache. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] memory fragmentation
Andrei Martynov wrote: > Tuesday, February 10, 2009, 1:27:53 PM, Jamie Lokier wrote: > > > The problem you have isn't really that it uses all memory for disk > > cache - that's a good thing > > I believe that any continuos memory (re)allocation is evil on nommu > platform with limited resources and should be avoided. > > How do others solve memory fragmentation problem? In general it's a hard problem. On no-MMU, Linux 2.4 mostly solved it with page_alloc2.c at some cost to performance. But even that doesn't work if you have something streaming large files from disk - additional tweaks are required, and they aren't completely reliable. There have been some efforts to solve memory fragmentation on big servers (with MMU) in Linux 2.6. Distinguishing short-lived and long-lived pages is part of that, so is moveable pages (I don't know if that fully works), and something called "lumpy reclaim". That's why I suggested trying a later kernel than 2.6.24, because some anti-fragmentation patches are in .26, .27, .29-rc4 etc. (Just download the ChangeLog files from kernel.org and you'll see fragmentation mentioned). Some anti-fragmentation patches aren't in the mainline kernels yet. I don't know if the server anti-fragmentation code is effective on a smaller no-MMU device. It's worth trying. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] limiting disk cache
Jamie Lokier wrote: > > Is there any way to limit disk cache size? > > There was a patch posted a few weeks ago I think, to limit page cache usage. It was on linux-kernel, I expect. For this particular problem, you might get better answers cross-posting to linux-ker...@vger.kernel.org as well as uclinux-dev. Although yours is a uClinux problem, a similar problem occurs in big servers trying to do high-order page allocations, and that sort of thing is discussed on linux-kernel. Enjoy, -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] limiting disk cache
Andrei Martynov wrote: > > I'm using kernel 2.6.24 with uClinux and ARM NOMMU patches. When one > application starts reading from disk kernel uses all available memory > for caching and other applications fail to start (not enough memory). > It takes kernel up to 10 seconds to release memory after the first > application exits. Yes, this is the reason we had mm/page_alloc2.c in Linux 2.4. That allocator is slow but reduces fragmentation, which is part of the problem you're seeing. There's no direct equivalent to page_alloc2.c in Linux 2.6, although there are other fragmentation reduction measures. 2.6.24 is quite old. You might get better results using 2.6.28 or 2.6.29, or maybe not. > Is there any way to limit disk cache size? There was a patch posted a few weeks ago I think, to limit page cache usage. The problem you have isn't really that it uses all memory for disk cache - that's a good thing - but that unreclaimable pages are sprinkled randomly around, and reclaimable contiguous regions hard to create, so memory is too fragmented for high-order allocations, which prevents new applications from starting. If you just limit disk cache usage, there's still a fair chance that the (limited) disk cache pages will be sprinkled all over memory, preventing apps from starting. It is worth a try, though. Unfortunately finding and keeping large reclaimable contiguous regions is not solved yet. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] enable /proc/PID/smap
Robert Wessels wrote: > Just a bit more background on this. As we all know, applications > running in a nommu environment have a static stack size. although the > maximum stack size is determined by this, the stack usage grows and > shrinks. One can imagine that in a certain condition the given > application can run out of stack. Hence one needs to grow the stack > either by recompiling the application or by use of flthdr (I believe). Threaded applications use an additional stack per thread, and possibly one more for the master thread with pre-NPTL LinuxThreads. What's more, the thread stack sizes are not determined by flthdr, and they can be different per thread. I've had to use this with threaded 'rsync', for example, because the thread stack size was too small, even if I set a large stack size with flthdr. > Rather than a trial and error way of doing this I am looking into > writing a tool that monitors the applications stack size for a period > of time and records the minimum and maximum stack usage. If the output > of this shows that the max stack usage comes close to the maximum > stack size, allocating a larger stack size is advisable. That would be really useful. Perhaps the thing to do is 'red-zone' the stack: during exec, fill the stack with a byte sequence which is unlikely to be written by the application itself. Later, look at the stack to find the first byte which doesn't match the red-zone pattern, to find how much stack was used. Just sampling the stack pointer register on a timer, would miss large transient stack usages. You could also look at GCC's options for stack bounds checking, but that would need the whole application and libraries to be compiled with it. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Stack overflow in the readdir
Davide Zanni wrote: > Hi all, > I have an application that display the content of an USB key with > the function readdir. This work fine but with an USB key the application > crash because in the file uClibc/libc/sysdeps/linux/common/getdents.c > the compiler try to allocate about 31K of data with the function "alloca > (red_nbytes)" and the default stack size is 12K in the thread that use > the function. To solve the problem I have increased the stack size of > that thread. > For the other program that use uClibc and the function readdir, like > busybox, it's possible that the program will crash. It's possible change > the allocation of the memory with the malloc to solve the problem for > all the application? Perhaps this should be sent to the uClibc mailing list instead. A few places in uClibc have this problem. I found the regular expression calls often overflow the stack and crash the app, or worse, cause strange behaviours. It's difficult to know how much stack an app should have to avoid these problems. In my own programs which use alloca, I use malloc/free pairs instead when compiling for uClinux: #ifdef NOMMU # define tmp_alloc(size) xmalloc(size) # define tmp_free(ptr) free(ptr) #else # define tmp_alloc(size) alloca(size) # define tmp_free(ptr) ((void) 0) #endif -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Chris Gray wrote: > On Monday 02 February 2009 22:01:12 Jamie Lokier wrote: > > > I didn't use Java because I thought it wouldn't fit, to be honest. > > > > There's about 10MB free on my 64MB device (32 allocated to video > > coprocessors, away from Linux; the rest is used by Linux, utils etc.) > > I found that's actually not enough when streaming from hard disk - > > because Linux's page allocator can't handle it, playback struggles. > > > > So I thought adding Java would make it worse. > > It probably would have: you can certainly run Java applications in less than > 10 MB (or even 5 MB), but you need to keep them pretty simple (and when the > memory consumption starts to grow it can be hard to put your finger on just > why). OTOH I know people who are doing pretty complex stuff (including > genetic > algorithms, would you believe) in something like 18 MB. That's good to know. My customer wants to use Java, I can use this to say "no, bad idea!" :-) Even if it fits in 5MB, the trouble is the system needs 10MB _free_ to stream from hard disk reliably. Linux 2.4 with the "page_alloc2" fragmentation-avoidance allocator cannot release page-cache due to streaming I/O smoothly, and with "page_alloc" (the normal Linux allocator), it's smooth but quickly fragments so much that launching new apps, such as shell scripts or telnet shells stops working. > There are some aspects of Java which make it hard to keep the > memory consumption real down low - the reflection data for example > (all those strings!) and the frustrating lack of modularity in the > class libraries. Yes you can compile stuff AOT and strip out unused > methods and reflection data - but be careful because the Java > libraries themselves use reflection quite a lot. The good news is > that once you have a certain critical mass of commonly- used core > classes from java.lang, java.io, java.net and java.util loaded the > memory consumed by class libraries starts to stabilise a bit - > provided of course that you don't start dragging in every cute > open-source library you see on the web. And of course, no MMU means no swapping in just those parts of the libraries which are used, so you really need enough RAM. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Chris Gray wrote: > You can also apply the same kind of thinking within a single-process > multi- threaded model, if you can find the right boundaries. For > example in OSGi the unit of granularity might be the service: if a > service is critical then some other service should be monitoring it > and be ready to take action if it appears to be stuck. The last > resort is to exit the JVM, and then at the linux scripting level > save the stack trace and relaunch Java. With no MMU, any process can clobber memory of any other process. So the last resort is the watchdog chip, in case it all went horribly wrong. I am *so* glad we have a watchdog chip on board. No so pleased with the occasional spontaneous reboot without kernel panic message :-/ But it's better than a locked up remote system. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Jamie Lokier wrote: > On my video player, the control program just runs the media player in > a child process and talks over a pipe to it, in simple text commands. > So the control program can be in any language, in theory. This is also quite handy when the codec crashes or gets stuck... the control program doesn't crash, it just kills the media program and starts another... -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Jonathan Wong wrote: > Hi Jamie, > > > My solution is to use Sigma's GCC 2.95.3 when building a program that > links > > to their libraries, but use newer GCC for other programs (that don't use > > Sigma's libraries at all). > > And then use JNI to call Sigma's libraries? That dashes my hopes to port > whatever I do on the Sigma to Windows XP Embedded later on. I'd use JNI to call a simple video play/stop/set-file API written in C, or (more likely) send commands to a local socket or talk over a pipe. On my video player, the control program just runs the media player in a child process and talks over a pipe to it, in simple text commands. So the control program can be in any language, in theory. I didn't use Java because I thought it wouldn't fit, to be honest. There's about 10MB free on my 64MB device (32 allocated to video coprocessors, away from Linux; the rest is used by Linux, utils etc.) I found that's actually not enough when streaming from hard disk - because Linux's page allocator can't handle it, playback struggles. So I thought adding Java would make it worse. However, you have 128MB total, which is a lot more room. And you're just streaming video over the network, which works better. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Jonathan Wong wrote: > I won't need a web browser, just a thin client to communicate with a > central server. You can write a client in any language. Java seems a bit heavy and hard to get going, if you don't specifically need Java on it. > I was just told our device doesn't have RAM at all, only 8MB ROM. Is that > possible? It'll have RAM, the EM8623 needs it. It's internal cache isn't big enough to run Linux. :-) 128MB RAM is the maximum it can use, without special hacks, and that's probably how much you've got, because 64MB is too small for H.264 support and Linux at the same time. > All these EABI/OABI stuff seems complicated. I have to compile different > parts of my application with different compilers? No, you can just use the compiler distributed by Sigma Designs if you like, it's not a bad compiler, just old. Sigma's EM8623 SDK is based on very old tools: GCC 2.95.3 and Linux 2.4.26-uc0, which are both ancient (about 5 years old). Also uClibc 0.9.26 and Busybox 1.00, again rather old. That's fine, as long as you stay with old software from 5 years ago ;-) Some new things you might want to use (you did mention J9!) might not compile with GCC 2.95.3; then you have some fun. But mostly, things work, it's not a bad compiler. Just old. It does have a few ARM bugs. If you find you need to use a new compiler, then you have to be careful about compatibility issues linking to Sigma's SDK binary libraries. If it was all open source there would be no problem, we'd recompile everything with current tools, but because it's closed that needs Sigma's cooperation. My solution is to use Sigma's GCC 2.95.3 when building a program that links to their libraries, but use newer GCC for other programs (that don't use Sigma's libraries at all). -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Minimum size of uCLinux and J9 compatibility
Jonathan Wong wrote: > Can I use your "Mika"? Is the EM8623 an ARM9 or ARM7? EM8623 is an ARM7 I believe, with no MMU. For SMP8634 and beyond, they switched to MIPS with MMU :-) The codesourcery toolchain uses ARM EABI, but the Sigma Designs libraries as OABI, so watch out. You have to use the right compilers... > I need to create a media player and include web connectivity (very thin web > client). Do I use CLDC or CDC? It could come down to size constraints, > though. Your main constraint will be memory, indeed. Max RAM with EM8623 is 128MB, and some portion, about 40MB, must be kept separate for video. That does not leave much for a web browser, if you have high-resolution pictures or large fonts. It'll be a squeeze. But it is just about enough for basic pages. I predict your biggest problem after getting a browser will be memory fragmentation, which prevents all the memory being used with 100% efficiency - especially when streaming video and/or switching between complex web pages. By the way, there are some non-Java web clients for these devices. Opera is available, that's probably good. Some others look less good, but it depends what you're displaying. > I was told codecs are included in the processor. Is that possible, or just > marketing talk? There are several codec co-processors in the chip, connected to the ARM part. They are quite good, for the price, although struggle a bit at the highest resolutions. You need to load codec binaries, but they are loaded into the co-processors which are specially designed for it; they don't do much on the ARM itself. > I'm asking the manufacturer about RAM sizes. Whatever the RAM size is, I'm > stuck with it. The hardware has already been bought by somebody on the team. Max size RAM, last I heard, is 128MB total (including video memory) on EM8623. Best of luck, -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
Daniel Jacobowitz wrote:
> On Thu, Jan 29, 2009 at 06:12:15AM +0000, Jamie Lokier wrote:
> > I wouldn't be surprised if the Codesourcery tools (especially
> > pre-built libs) are targetting later ARM chips only, since people
> > using later ARM chips are probably paying Codesourcery for the work.
>
> Our tools support all (post-V4) ARM processors; I believe that we
> package libraries for all processors too nowadays. The defaults may
> be fairly modern, though - so as Jamie said, be sure to tell the tools
> what you want your code to run on!
ARM has a huge number of instruction set variants. This is a quick
guess, I'm no expert (but I've already been daunted when looking into
ARM FDPIC-ELF, simply at the number of different ways jumps and calls
are encoded)):
{ OABI, EABI soft-float, EABI hard-float }
times
{ ARMv4, ARMv4T, ARMv5, ARMv6, ARMv7 (?) }
times
{ not Thumb, Thumb, Thumb2 }
times
{ Thumb interwork or not }
times
{ non-PIC, PIC, PIC+single-pic-base }
Do you really have a policy of including pre-built multilib-ed libc
and libstdc++ as well as libgcc for all the combinations that make
sense?
My approach these days is to build all libraries including libgcc
specifically targetted at the CPU variant being used by whatever
projected I'm using. It saves headaches from things that crash
spontaneously otherwise. I haven't tried the Codesourcery ARM tools
yet, though I intended to soon.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
> make[2]: Entering directory `/home/cc/Desktop/temp/uClinux-dist/user/busybox' > LINKbusybox_unstripped^M > Trying libraries: crypt m^M > Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group > Output of: > ucfront-gcc arm-linux-gcc -Os -g -pipe -msoft-float -fno-common -fno-builtin > -Wall -DEMBED -D__PIC__ -fpic -msingle-pic-base -Dlinux -D__linux__ -Dunix ^ > -D__uClinux__ -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes Those are the flags for XIP. Can you turn off XIP? I've had problems on ARM-nommu with XIP and some toolchains, possibly the one you're using. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > 2009/1/29 Jamie Lokier : > > loody wrote: > >>e1a0e00fmov lr, pc > >>e12fff13bx r3 > > Actually my cpu get exception when executing this instruction not bx r3. > But lr is the destination for cpu to write, I have checked the arm > reference and it doesn't say any cautions when the destination is lr. You're right, that doesn't make sense to me either. > > "bx" is not available on all ARMs, and will fault when you don't have > > it. That's why it's necessary to build everything with the right GCC > > options. > > There are bx instructions generated when I use arm-linux-2006. > > BTW, can I take off the Thumb support in my compiler options? > Thumb is only used for decreasing the density of source code and so > far I just want my kernel say hello to me. At this point, you may want to subscribe to the linux-arm mailing list, and ask the question again there :-) http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: >e1a0e00fmov lr, pc >e12fff13bx r3 > What is the specialty of the instruction, "mov lr,pc", which let > arm cpu fail? Both of those instructions can put the CPU into Thumb mode. If it doesn't support Thumb, you get an instruction fault. "mov lr,pc" is supported on all ARMs, but (guessing from what you're getting) maybe it can fault depending on the value in "lr"? "bx" is not available on all ARMs, and will fault when you don't have it. That's why it's necessary to build everything with the right GCC options. I wouldn't be surprised if the Codesourcery tools (especially pre-built libs) are targetting later ARM chips only, since people using later ARM chips are probably paying Codesourcery for the work. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote:
> When I use "-Wl,-elf2flt,-s32768" to compile my hellow.c.
It should say "-wL,-elf2flt=-s32768". Note the "=" (equal sign).
> b.
> When I use "-Wl,-elf2flt" to compile my hellow.c.
> it will say:
> arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified
> for loadable section `.plt'
> collect2: ld returned 1 exit status
Something's wrong with the GCC options or with libc.
There should be no no ".plt" section when compiling for ARM-nommu.
Use "readelf -hledS hello.elf" (whatever ".elf" file is created by
GCC) to see what sections it has. For your ARM type, it should not
have ".plt" or ".got".
If it's wrong, you can use "-v" with GCC (and all the other options)
to see how it's linking. That might give a clue.
> c.
> so I try to use arm-linux-uclibcgnueabi-elf2flt to meet my requirement.
> And it say:
> TEXT -> vma=0x0 len=0x24
> DATA -> vma=0x0 len=0xc
> ERROR: text=0x24 overlaps data=0x0 ?
Are you running that on a linked ELF _executable_ (a.out) or an ELF
object file (*.o)? Looks like a *.o to me.
> it seems i need to modify some file to fix b and c. But I cannot find
> any config about elf2flt.
You should never run elf2flt yourself. Always let GCC do it.
> And it seems ALMOST work.
>
> ALMOST means I can see the kernel message says
> "tart_thread(regs=0x83c15ef8, entry=0x83d60044,
> start_stack=0x83d6ffb0)"
> but I cannot see the "hello" that I am looking for.
To some extent, the toolchain's uClibc must match the kernel you're
using, too.
> 1. I guess the reason why I cannot see the "hello" from console is due
> to some lib I have to put at root file system/lib. But I don't know is
> there any tool like readelf can tell me what lib flt needs? I only can
> do is use "file". But it only can tell me the format not the detail
> information. If someone knows any tool for flt, please let me know.
You can use "readelf" on the "a.out.elf" or "hello.elf" file that's
created by GCC. When compiling with "-Wl,elf2flt=-s32768", you get
_two_ output files. One's a flat executable which you run, and the
other ends with ".elf". You can run tools like "readelf" and "nm" and
"nm --dynamic" on the ELF file.
> BTW, is my hello.c too complicate that it fail to print message on console?
> #include
> int main()
> {
> printf("Hello World");
> return 0;
> }
It's fine.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] build uclinux successfully but get cpu unknow exception
loody wrote: > > Try adding "-mcpu=arm940t" to the GCC command, and remove > > "-march=armv4t" and "-mtune=arm9tdmi" from it (your example has them). > the situation is still the same when I follow the instructions you suggest. > (I use Codesourcery gcc but assign buildroot lib.) Ah... The faulting instruction is probably in a library, probably uClibc. The library needs to be compiled with the right CPU/arch options too. If you're using buildroot, check it's using the right CFLAGS for your chip when building uClibc. Edit the buildroot script if necessary. It could be in libgcc.a instead; that's more fiddly. You might not be able to use the precompiled GCC from Codesourcery if that's true. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] build uclinux successfully but get cpu unknow exception
loody wrote: > I download the arm-toolchain from codesourcery, > arm-2008q3-68-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2 and > arm-2007q1-10-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2. > > But my cpu will get "Undefined instruction" each time, when executing > the assembly below: > [0xe1a0e00f] mov r14,pc > [0xe12fff13] bx r3 > > my cpu is arm940T. Try adding "-mcpu=arm940t" to the GCC command, and remove "-march=armv4t" and "-mtune=arm9tdmi" from it (your example has them). -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > "File is not an object file" > so, it seems I have to make a object relocation file to let this tool, > arm-linux-elf2flt, work. > but how? Don't use the tool directly, use it with GCC as you found: > 2. I use "-Wl,-elf2flt=-s1024" with arm-linux-gcc and it says: > > /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: > address 0x53880 of a.out.gdb section .text is not within region > flatmem > /media/sda6/uclinux/usr/local/bin/../lib/gcc/arm-linux/3.4.4/../../../../arm-linux/bin/ld.real: > error: no memory region specified for loadable section > `__libc_freeres_fn' > collect2: ld returned 1 exit status With a proper toolchain including uClibc _from that same toolchain_ it just works. If you mix with uClibc from elsewhere, then it may fail. Note that some toolchains don't have uClinux no-MMU support. Unfortunately there isn't a good site pointing to all the latest good toolchains for each target. (By the way, you will need a bigger value than 1024 in the option -Wl,-elf2flt,-s32768. That shouldn't affect compiling and linking, but 1024 is too small and the program is likely to have problems when you run it.) > it seems the elf2flt.ld need some modification, if I guess correctly. That's right. With all the toolchains I used, though, which come with their own uClibc, elf2flt.ld is already correct. Oh, unless you're using C++. C++ doesn't work properly with older toolchains. Try C. > 3. Do i use the wrong toolchain, since I use arm-linux instead of > arm-elf. If so, where I can download arm-elf toolchain as arm-linux > did on uclinux.org, except those obselete. They both work for creating C executables which run on uClinux. Yes, the links on uclinux.org are obsolete. Search the archive of this mailing list for more recent suggests. The Codesourcery ones get mentioned a lot. > BTW, I have use build root to re-get the toolchain. But when I enable > elf2flt config. the compile will show the error message below: > > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19-build/bfd/libbfd.a(compress.o): > In function `bfd_uncompress_section_contents': > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:96: > undefined reference to `inflateInit_' > /media/sda6/uclinux/buildroot-2009.02-rc2/toolchain_build_arm/binutils-2.19/bfd/compress.c:103: > undefined reference to `inflate' > make: *** [elf2flt] Error 1 I've never seen this. (But I'm intrigued by the possibility of compressed section support in binutils, which I hadn't noticed before :-) Your solution is to get a toolchain that others have used, better a more recent one, try a C program first (because C++ doesn't always work on older toolchains), and don't mix with other libraries. So try a "hello world" program first :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] why no-mmu cannot support binfmt_aout.c
loody wrote: > BTW, I also find that if I want uclinux kernel to support ELF binary > file, I also have to enable the mmu option. > But the format of cross-compiled binary file like busybox is only ELF, > if there is option I can add to let busybox and other binary files > compiled in different format. On uClinux with no MMU, you have to use FLT format (all architectures support this I think) or FDPIC-ELF (just a few architectures support this, the advantage is proper shared libraries and loadable modules). To make FLT files, usually you add "-Wl,-elf2flt=-s32768" or something like that to the GCC command line. That option sets the stack size; the size needed is different for each application. Too small and the app will crash or worse, corrupt memory. Too large and it'll use a lot of memory, and won't start at all after the system has developed memory fragmentation. Enjoy :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: DQ5 Checks in mtd drivers
Glenn Henshaw wrote: > Since no one seems interested, Sometimes you just have to post again. People are too busy to respond to every message, so some get missed. It doesn't mean nobody cares. This is normal on many mailing lists like this. But note that 2.4 kernels are not supported by official MTD authors any more, since they are way too old. If the problem is still present in current 2.6 kernels, then they may be interested in your fix. > does this absolve me from my GPL obligation to submit the code > upstream? It doesn't change or absolve any obligations. You haven't understood the GPL. The GPL does not create any obligation to submit the code upstream, or to make it public. The GPL means when you give someone compiled code, you have to give _those_ people the exact corresponding source code (i.e. with your changes, exact same version etc.), or you must give them access to that source code. The GPL explains several different ways you can do this. So you do have an obligation, but it's not what you've implied, and it doesn't have anything to do with upstream. Publishing the changes publically and submitting the code upstream is a good idea anyway, for many reasons, but it's not an obligation. > > I have just managed to update a system from an older 2.4 kernel to > >the most recent 2.4.34.5-uc0 version. I know the feeling, as I'm just forward porting something using 2.4.26 right now, and I know someone doing the same for a device using 2.4.19 :-) > >It looks like there were some checks added to the AMD FLASH drivers > >that totally break SST FLASH devices. > > > > 1) Where is the best place to complain? Was the old functionality > >hidden somewhere? > > 2) Where is the best place to submit the patch to support SST > >39VF320x and 39VF640x devices? If the problem is present in current 2.6 kernels, it would be good to post about it again, this time explaining that it's in 2.6 kernels. The MTD authors have moved on from 2.4 kernels a long time ago and no longer support them. If the patch is reasonably clear and sane, and doesn't break anything else (such as other flashes) you may submit it to the general Linux 2.4 maintainer, Willy Tarreau last time I looked. I guess if nobody reviews your patch but it's an important and well-contained fix, that's the best you can do. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Porting Sigma Designs EM8xxx to latest 2.6 kernels
Andrei Martynov wrote: > I'm porting Sigma EM85XX patches from 2.4.17 to 2.6.24 kernel. The > kernel is configured as Very interesting. Is it an official port? I'm porting Sigma EM86xx patches from 2.4.26 to 2.6.28. I'd be interested in any common ground, which there might be a lot of especially in the drivers and (ARM-nommu + Sigma specials) architecture code. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
Lin KJ wrote:
> - The compiler version newer than gcc-4.x can NOT be used for XIP uClinux
> because of the
>"R_ARM_GOTOFF32" relocation type. It will produce the "R_ARM_GOTOFF32"
> relocation which will be resolved by adding a negative offset from the
> GOT. However,
> in the XIP uClinux, the GOT does not immediately follow the .text
> section, so a negative
> offset from the GOT expecting to find the .text section does not make
> any sense.
> For example:
> d6: 4803 ldr r0, [pc, #12] (e4 <.text+0xe4>)
> d8: 4450 add r0, sl
>
> e4: ffdc undefined
> e4: R_ARM_GOTOFF32 .LC0
> - Following code can be used to test the "R_ARM_GOTOFF32" relocation
> type.
> void g(void (*h)(void)) {}
> static void f(void) { g(f); }
If GCC-4.x *with -msingle-pic-base* is assuming the GOT is a fixed
offset relative to .text, that's a GCC bug. The purpose of
-msingle-pic-base is to disable that assumption.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
Gavin Lambert wrote: > > dist/vendors/config/armnommu/config.arch" file? > > Usually in your board-specific config.arch file (not the generic armnommu one > -- the one that you selected in the toplevel Makefile) there are three lines > like this: > > # DISABLE_XIP := 1 # XIP works fine > # DISABLE_MOVE_RODATA := 1 # move-rodata is fine > # DISABLE_SHARED_LIBS := 1 # shared libs are fine > > Uncomment all three of these to disable XIP. You will also need to do a > complete rebuild (make clean), otherwise you can have mixed object files, > which cause problems. So we conclude that the tool on uclinux.org does incorrectly compiles the generic ARM-nommu architecture support from uclinux.org? I've been collecting posts related to toolchains from uclinux-dev for a while, so that I have a clue next time I need to find a working toolchain. There are quite a few toolchain branches, and seemingly no reliable authority for compiled toolchains that work for every target variation. Nor even a place where you can be sure all the patches get to "eventually". Back in ye olde days we posted GCC patches to the GCC developers and they appeared in GCC releases :-) The toolchain links on uclinux.org are a bit hit-and-miss, depending on what you're building for. Between the lines (it could be more clear) is "Try this toolchain - it works very well for us - but it's work in progress and you'll need a toolchain from somewhere else (find it yourself) for some configurations different to ours". I'm wondering if uclinux's toolchain page could be a bit more informative about the locations of toolchains that people ought to try, instead of offering a single one and no hint that it's not for everyone? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] gdbserver on MMU-less boards (mini-HOWTO)
Bernd Schmidt wrote: > Jamie Lokier wrote: > > It's also possibly to do atomic memory operations the way older > > versions of ARM do cmpxchg (they don't have an instruction for it). > > > > They call a routine in the kernel address space (but not a syscall). > > Kernel task switching checks if the intruction pointer is inside that > > code sequence, and restarts the cmpxchg sequence if it is. That makes > > it effectively atomic without disabling interrupts, and works with > > normal userspace protections. It doesn't work on SMP, but we assume > > SMP ARMs will be a newer version which has atomic instructions. > > We do exactly the same thing on the Blackfin. I thought I'd invented > the technique - apparently not. I'm sure the technique is much older than Linux :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] gdbserver on MMU-less boards (mini-HOWTO)
Michael Schnell wrote: > (Re Futex I do know that the NIOS ISA does not have any "monolithic" > memory read/modify/write instructions and thus does not allow for > implementing Futex with a full Linux (using the MMU), but without > protection a thread just can do di/ei and thus no Kernel action needed.) > > Any more thought ? It's also possibly to do atomic memory operations the way older versions of ARM do cmpxchg (they don't have an instruction for it). They call a routine in the kernel address space (but not a syscall). Kernel task switching checks if the intruction pointer is inside that code sequence, and restarts the cmpxchg sequence if it is. That makes it effectively atomic without disabling interrupts, and works with normal userspace protections. It doesn't work on SMP, but we assume SMP ARMs will be a newer version which has atomic instructions. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] ARM compiler option "-msingle-pic-base"
Jun Sun wrote: > On Thu, Nov 27, 2008 at 02:24:48AM +0800, Lin KJ wrote: > > In the ARM uClinux world, it seems that the user land XIP code should be > > compiled with the "-fpic" and "-msingle-pic-base" flags. > > Why not just "-fpic" flag? > > Is it concern with the elf2flt tool? > > I think it has more to do the loading FLAT executables. FLAT > does not need run-time loader. As a result, relocatable symboles > are only fixed up once by kernel. Single pic base would be much > eaiser to do for this case. That's not the reason. When using XIP, FLAT executable code is never relocated by the kernel, while the writable data segment is relocated every time you start the executable. (Non-XIP excutables relocate both the code and data at every time.) The reason you need -msingle-pic-base is because the data segment is at a separate, independent location from the code segment. With traditional PIC, the data segment is always PC-relative a fixed offset from the code segment, and PC-relative instructions are used to access data from the code. This is not true for XIP, hence the extra option so the data segment address is passed in a dedicated CPU register. > > I can have the applications and uClibc to be compiled with > > "-msingle-pic-base", but how about the libgcc.a? Does the > > libgcc.a have to be produced with the "-msingle-pic-base" too? Some parts of libgcc.a will work without -msingle-pic-base, but some parts may need it. Many programs don't use all of libgcc.a. I see in the ARM uClinux toolchains I'm using that there are multiple versions of libgcc.a, and if -msingle-pic-base is used to link a program, then it selects the version of libgcc.a which was compiled with that option. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] gdbserver on MMU-less boards (mini-HOWTO)
Michael Schnell wrote: > >I'm not sure if gdbserver is working with pthreads on non-mmu at all, > >because the threads are in the same address space. > I don't see this problem right now. The threads are in the same address > space with and without MMU, so this should not make a difference. It was poorly phrased. Without MMU, everything is in the same address space, including different processes. To distinguish state, each process is either post-linked (relocated) when it is started, or a dedicated CPU register points to process/thread-specific state. Since this is done quite differently with/without MMU, GDB needs specific code for each one to debug threads without an MMU (and even processes, but that's already done). To complicate further, some no-MMU architectures have old-style pthreads (Linuxthreads) and new-style pthreads (NPTL aka TLS), as well as non-PIC and PIC ABIs, and all combinations use dedicated CPU registers to access thread/process state in different ways. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: Methods to reduce latency?
Xin Xie wrote: > The standard way to decrease the latency for embedded system is using a > real-time kernel running alongside with uClinux and keeping the > real-time task inside the real-time kernel. Not too sure if that already > supported in the NIOS uClinux. Yes, although nowadays the RT-PREEMPT changes (different from PREEMPT!) achieve a similar effect without needing a separate kernel. Either your suggestion, or RT-PREEMPT, can often reduce interrupt handling latency and keep it stable, provided that it has sufficient priority over other tasks. But then you have the latency of the network stack, which may be a bit more copmlicated because it interlocks with so many things. You may find RT-PREEMPT + ensuring the network softirq tasks have RT priority as well as your task does the trick. The catch is the architecture-dependent parts of RT-PREEMPT are not written for all architectures - and on some (e.g. ARM) some versions seem to be a bit unstable. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: Methods to reduce latency?
Michael Schnell wrote: > > >But, it turns out to be moot. The kernel hangs when HZ is 1000 > >and resets immediately when HZ is 250 or 300. It could be that > >the system tick timer isn't configurable and is hard-wired to > >generate a 100Hz interrupt. > > > IMHO: if we are to fix any bugs in the system timer functions, we should > consider to enable the "tickless timer". With same the overhead should > be reduced drastically. Of course we need a programmable timer > "hardware" for this, but same might be in place anyway (Altera timer) > or could quite easily be done using VHDL. Yes, not just reduced overhead, but (depending on what's already working on that platform) high-resolution timers and fairer scheduling in the presense of interrupts, too. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: Problem of build bonnie++ in uClinux-888
Arthur Wong wrote: > Not need. > > Content of the compiler is not changed, it just be moved to the other > directory. > I think it's easy to swap one toolchain to another in this way. Some toolchains don't work properly if they are moved to another directory. It's because they have hard-coded absolute paths compiled in. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: Problems with simple pthreads app on NIOS2
Grant Edwards wrote: > On 2008-11-04, Grant Edwards <[EMAIL PROTECTED]> wrote: > > > On the NIOS2 target, it works fine if I only connect to 1-2 TCP > > ports, I can close the connection and then reconnect. when I > > connect to more than two ports, everything works fine until I > > close the connections. Then my app usally exits with an error > > (status==1) and no messages of any sort. I have seen it work > > OK after 3 connections have been opened and closed, but it > > usually fails. > > Somebody on the NIOS2 forum pointed out that printf() isn't > thread safe (that was news to me). So I serialized calls to > printf(). That made the output look a little cleaner but > didn't change program behavior: the application still exits > spontaneously when connections are closed. printf() _should_ be thread safe, like the other stdio functions except the *_unlocked variants. -- Jamie > > -- > Grant Edwards grante Yow! Hello... IRON > at CURTAIN? Send over a >visi.comSAUSAGE PIZZA! World War >III? No thanks! > > ___ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] patch file for the "e2fsprogs" app of uClinux-dist-20080808.tar.bz2
Mike Frysinger wrote:
> On Monday 20 October 2008, Chris Gray wrote:
> > On Monday 20 October 2008 19:23, Jamie Lokier wrote:
> > > Mike Frysinger wrote:
> > > > > @@ -237,9 +237,9 @@ int main(int argc, char **argv)
> > > > > send_output("\n", 0, send_flag);
> > > > >
> > > > > if (outbuf) {
> > > > > -pid = fork();
> > > > > +pid = vfork();
> > > > > if (pid < 0) {
> > > > > -perror("fork");
> > > > > +perror("vfork");
> > > > > exit(1);
> > > > > }
> > > > > if (pid) {
> > > >
> > > > but this one is wrong because the child will call exit() after
> > > > writing its log
> > >
> > > It's ok to call _exit() in a vfork-child, but not exit().
> > > So that should be changed.
> > >
> > > Writing the log in a vfork-child is dodgy, depending on how it's done.
> >
> > If vfork returns < 0 then the fork failed and no child process was created,
> > n'est-ce pas? So we are executing in the parent.
>
> read the whole code. there's an exit() in the non-error case. i wasnt
> referring to the exit() that happened to be in the patch shown.
Btw, in most cases exit() should not be called in a *fork* child
either, let alone *vfork*. It will flush stdio buffers - and they may
get flushed by the parent when it exits too. Same for atexit()
handlers.
Often if there's an exit() in a fork child and the parent too, one of
them should be _exit(), and it's usually the child.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] patch file for the "e2fsprogs" app of uClinux-dist-20080808.tar.bz2
Mike Frysinger wrote:
> > @@ -237,9 +237,9 @@ int main(int argc, char **argv)
> > send_output("\n", 0, send_flag);
> >
> > if (outbuf) {
> > -pid = fork();
> > +pid = vfork();
> > if (pid < 0) {
> > -perror("fork");
> > +perror("vfork");
> > exit(1);
> > }
> > if (pid) {
>
> but this one is wrong because the child will call exit() after
> writing its log
It's ok to call _exit() in a vfork-child, but not exit().
So that should be changed.
Writing the log in a vfork-child is dodgy, depending on how it's done.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
David Howells wrote: > Jamie Lokier <[EMAIL PROTECTED]> wrote: > > > Fwiw, on 2.4 I use an in-house ramfs-like driver which allocates the > > pages contiguously for each file, and that works nicely. > > But that's not XIP. The 2.6 mmap code will attempt to do that for you for > private R/O sections and then share them if possible behind the scenes. Oh, excellent. The 2.4.26 mmap code does not do that, which is why I needed the driver. It's not XIP in ROM, but is sharing code segments in RAM in the same way (and same compiler options), which is critical for my application. It reduces no-MMU fragmentation considerably. You say private R/O - not shared R/O? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] XIP on uclinux 2.6, fantasy or reality?
David Howells wrote: > Jun Sun <[EMAIL PROTECTED]> wrote: > > > That seems to indicate XIP does not work at all for 2.6. Can > > someone confirm? > > It depends. It may work from ramfs, if the pages for each individual > shareable mapping are contiguous. It won't work for ROMFS on MTD without > patches, and those are currently pending on the MTD maintainer. Fwiw, on 2.4 I use an in-house ramfs-like driver which allocates the pages contiguously for each file, and that works nicely. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] pthreads, vfork and signals
Allon Stern wrote: > Never mind NPTL - I just want Linux Threads, which don't seem to be > working for my on my NOMMU M5282 target, using 888. > I'm using uClibc 20060608 > > Anybody have it working? A simple example causes an illegal instruction. I get an illegal instruction when using Linux Threads on ARM-nommu with arm-uclinux-elf-tools-base-gcc3.4.3-20050221.sh, The illegal instruction happens before main(), and GDB cannot debug it. If I use that compiler but with options to link to a uClibc from an older toolchain distribution, it works. (That's what I'm doing now.) So it's possible your problem isn't lack of support, but a toolchain that's broken somehow. Have you tried using a different one? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: Trouble flashing a Snapgear Pro
Grant Edwards wrote: > > Of course you have to remember that most people using these > > devices are not Linux aware at all. These are "consumer" level > > devices. > > You're right. A windows machine is the one thing that everbody > can be counted on to have. That's a curious assumption which is definitely not always true. I've had difficulty a few times when people assumed I had ready access to a Windows machine. I do now, but only since purchasing a copy second hand. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] irc on freenode #uC-Linux
rwarner wrote: > >>Not sure this will be used, guess i'll wait to see if it's useful. Have > >>setup an irc on freenode #uC-Linux. It's not visible on the /list, but > >>if you /join #uC-Linux you will get in. Was wondering if this would be > >>a good place for quick communication when needed by the uclinux > >>developers. > > > >Why not #uClinux, which is the actual name? > > > >(There was a uC-libc library, which is no longer used. uClibc is > >current though. You see why the "-" makes a difference...) > > the #uCLinux was already there and not in use. someone previously setup > an irc and it appears it has not been used. > > (08:35:21) ChanServ: (notice) #uclinux is already registered to Lifeeth. > > And it appears it hasn't been used or maintainable, though i could be > mistaken. > > Either is fine by me, but would assume it would be good if someone > maintained/administrated the channel. Anyone know who Lifeeth is? Does it need to be actively maintained? I thought it was enough to just use the channel. Having both #uclinux and #uC-linux seems confusing and silly, especially as #uclinux already exists and nobody's choosing to use it. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] irc on freenode #uC-Linux
rwarner wrote: > Hi all, > > Not sure this will be used, guess i'll wait to see if it's useful. Have > setup an irc on freenode #uC-Linux. It's not visible on the /list, but > if you /join #uC-Linux you will get in. Was wondering if this would be > a good place for quick communication when needed by the uclinux developers. Why not #uClinux, which is the actual name? (There was a uC-libc library, which is no longer used. uClibc is current though. You see why the "-" makes a difference...) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Bootloaders: u-boot vs. micromonitor
rwarner wrote: > Martin Euredjian wrote: > >Why would one choose one over the other? > > > There is another option versus the ones above. I wrote my own as U-Boot > above appeared 'heavier-weight' then what is needed. Though i may have > missed something in the requirements of uCLinux start up. > 1. Initialize and provide access to RAM/ROM and peripherals > A. change PLL > B. change chip select registers for RAM/ROM > C. setup AIC > D. setup WDT as necessary > E. ensure other peripherals are in a quiescent state > 2. jump to 'stext' That's good for a first stage bootloader. You might use it in a rolled out system where you only update to tested firmware, or when you have pins on the board to easily reflash it. Often it's useful to have a second stage with options to trap on a diagnostic serial port, present a prompt, boot an alternative kernel, read a file from the network and write it to flash, etc. Sometimes the second stage can be a small Linux kernel :-) -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] CONFIG_USER_BUSYBOX_MD5SUM breaks pthreads?
Wolf, Josef wrote: > OK, I've tracked it down now. Seems to be a stack overflow in busybox. > Adding > > LDFLAGS += -Wl,-elf2flt="-r -s 65536" > > to user/busybox/Makefile solves the problem. Be careful: the "-s" option just changes the _initial_ thread's stack. The stack size for subsequent threads is hard-coded into libpthread, in uclibc. You can override it with pthread_attr_init, pthread_attr_setstacksize, and modifying all calls to pthread_create. Unfortunately no global run-time setting. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] msh: detect if a file exists
Michael Schnell wrote: > >You meant -e, and that does work with msh. > > > Thanks a lot, Jamie. That was the trick. > (In the bash documentation -a and -e are equivalent, so I stopped > reading when I found -a.) > > How did you know this ? Do you have an msh documentation ? I did "man sh", "man test" or "man [" - all of them (on Ubuntu) have -e but not -a for file testing. :-) There's no msh documentation as far as I know, but it's basically a standardish old-style Bourne shell with some bugs, and notably no user-defined functions (which are a modern feature anyway). So most "sh" documentation applies to msh. Bash is full of extensions to the Bourne shell, so a lot of what you see in the Bash documentation does not apply to msh. On some Linuxes "man sh" gives you Bash documentation; on others, it gives you Ash documentation which is closer to old-style Bourne shell. Having said all that, in your problem it's not the msh command at all. If you study Bourne shell, you'll see the command is "if COMMAND; then ...". So you are running the command "[ -e file ]". That means you need the documentation for the "[" command - there really is one :-) It's the same as the "test" command. It happens to be built in to some shells, including Bash, but not all. -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
