Re: [uClinux-dev] newest possible kernel version for trunk of uClinux-dist?
OK, but what to do about already existing code Fix the usage of it :-) I don't dare to, as I don't see a commonly agreed strategy. _I_ would just replace the code mentioned by p = vfork(); but I feel that we would get bashed (and no pushing upstream) for this as traditionally everybody is used to do fork() and vfork() seems to be lead some kind of secret life. Maybe a strategy might be to completely get rid of vfork() and do a compiler define vfork - fork in some top level make file but this asks for really nasty problems in those (many more than no) cases when the easy porting does not hold. (E.g. I just started using the boa version 0.94 instead of 0.93 and there seems to be a small vfork glitch: it does not return to the command line when started without the -d option. I did report this to the boa team.) IIRC the uClinux-dist adds the __uClinux__ for !MMU builds, so even if the toolchain doesn't define it you are ok. I'm positive that there will be a solution :). The name __uClinux__ just seems not very right. -Michael ___ 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] newest possible kernel version for trunk of uClinux-dist?
No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. With user space stuff I always found the EMDED define which often is used to do a fork() vs. vfork() selection. (Which IMHO in many cases seems silly, as AFAIK, you can happily use vfork() if there is an MMU, too, in nearly (?) all cases when you can _simply_ (without any other code change) replace fork() with vfork() anyway. ) Moreover the name of the EMBED define seems quite outdated, as today, many embedded devices do provide an MMU. I don't know if there is some change on that issue planned (e.g. using CONFIG_MMU, in User Land as well). -Michael ___ 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] newest possible kernel version for trunk of uClinux-dist?
My company is porting uClinux to our processor architecture that is used in several routers and some digital picture frames on the market. Is it a secret which arch you are talking about ? -Michael ___ 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] newest possible kernel version for trunk of uClinux-dist?
Hi Michael, Michael Schnell wrote: No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. With user space stuff I always found the EMDED define which often is used to do a fork() vs. vfork() selection. That was certainly the case many years ago... (Which IMHO in many cases seems silly, as AFAIK, you can happily use vfork() if there is an MMU, too, in nearly (?) all cases when you can _simply_ (without any other code change) replace fork() with vfork() anyway. ) Yes, pretty much true... Moreover the name of the EMBED define seems quite outdated, as today, many embedded devices do provide an MMU. Yes, definitely true. I tend not to use it any more. I don't know if there is some change on that issue planned (e.g. using CONFIG_MMU, in User Land as well). Currently I use __uClinux__ in userland for this. (Which isn't perfect either, if you use a standard gnu linux configured gcc for compiling uCLinux systems you need to manually define it too). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ 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] newest possible kernel version for trunk of uClinux-dist?
Jivin Michael Schnell lays it down ... No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. With user space stuff I always found the EMDED define which often is used to do a fork() vs. vfork() selection. (Which IMHO in many cases seems silly, as AFAIK, you can happily use vfork() if there is an MMU, too, in nearly (?) all cases when you can _simply_ (without any other code change) replace fork() with vfork() anyway. ) That is true, but to be sure everything is happy, it's often better to continue using fork on MMU systems, especially if there is any question over the safe use of vfork. Moreover the name of the EMBED define seems quite outdated, as today, many embedded devices do provide an MMU. Hmm, I thought that current SG/uClinux-dist mostly used EMBED for things that reduce code size (and often functionality at the same time) and __uClinux__ for true uClinux (ie !MMU) changes. I don't know if there is some change on that issue planned (e.g. using CONFIG_MMU, in User Land as well). In user space we use __uClinux__ for vfork/MMU differences. Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com ___ 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] newest possible kernel version for trunk of uClinux-dist?
(Which IMHO in many cases seems silly, as AFAIK, you can happily use vfork() if there is an MMU, too, in nearly (?) all cases when you can _simply_ (without any other code change) replace fork() with vfork() anyway. ) Yes, pretty much true... But userland software I all over the place see funny #defines for fork or things like #ifdef EMBED p = fork(); #else p = vfork(); #endif Moreover the name of the EMBED define seems quite outdated, as today, many embedded devices do provide an MMU. Yes, definitely true. I tend not to use it any more. OK, but what to do about already existing code I don't know if there is some change on that issue planned (e.g. using CONFIG_MMU, in User Land as well). Currently I use __uClinux__ in userland for this. (Which isn't perfect either, if you use a standard gnu linux configured gcc for compiling uCLinux systems you need to manually define it too). The NIOS uCLinux, I'm working with, some day soon will get a configuration setting if or if not an MMU is to be used, as the CPU itself can be configured to feature an MMU or not. The powers (Thomas) decided that it still is called a uCLinux distribution. So maybe a setting USE_MMU or something like this seems more appropriate. -Michael ___ 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] newest possible kernel version for trunk of uClinux-dist?
especially if there is any question over the safe use of vfork. Of course there are lots of cases where you can't just replace fork() and vfork(). But here you need a decent porting if you want to take care of the EMBED define. In other cases (the more common ones) it would be nice just to use vfork() all over the place. Moreover the name of the EMBED define seems quite outdated, as today, many embedded devices do provide an MMU. Hmm, I thought that current SG/uClinux-dist mostly used EMBED for things that reduce code size (and often functionality at the same time) and __uClinux__ for true uClinux (ie !MMU) changes. I believe this might be changing. I feel the uCLinux toolchain is more about the way of creating a distribution not about the k,ind of architecture used. (e.g. the NIOS architecture will be optionally available with and without MMU. ) -Michael ___ 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] newest possible kernel version for trunk of uClinux-dist?
Hi All, My company is porting uClinux to our processor architecture that is used in several routers and some digital picture frames on the market. We started with the 20080808 distribution (2.6.25-uc0 kernel) and have a kernel up and are adding drivers and user mode code currently. Our architecture has nommu but SMP support, gpios and other things that we see are in great flux in the mainline kernel. The latest patch in http://www.uclinux.org/pub/uClinux/dist/patches/ is uClinux-dist-20080808-20090112.patch.gz, same as on http://sourceforge.net/project/showfiles.php?group_id=240583package_id= 292947 both contain a patched 2.6.26 kernel now, also under http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/ I find linux-2.6.26-uc0.patch.gz as the latest patch. In one of the recent postings here I saw it mentioned that Linus has a -uc0 branch in addition to mainline. And from another email I concluded that __uClinux__ is a conditional that surround nommu-isms in the kernel source but grep -r __uClinux__ * gives me nothing in the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git. One of my colleagues says that uClinux is fully integrated in the mainline kernel now but seeing the patches for 2.6.26 and not finding anything with my grep confused me a bit and just trying with 2.6.28 or newer is several days of work. Could someone please tell me which kernel is the newest that I can use to put our architecture code in and run the uClinux userland code and libs underneath? I only checked the FAQs on uClinux and uCdot and I am reading uClinux-dev since about a month. If there is a better source of information I would be happy with any kind of: read this mailing archive / website kind of answer. - Rainer ___ 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] newest possible kernel version for trunk of uClinux-dist?
Hi Rainer, Rainer Keller wrote: My company is porting uClinux to our processor architecture that is used in several routers and some digital picture frames on the market. We started with the 20080808 distribution (2.6.25-uc0 kernel) and have a kernel up and are adding drivers and user mode code currently. Our architecture has nommu but SMP support, gpios and other things that we see are in great flux in the mainline kernel. The latest patch in http://www.uclinux.org/pub/uClinux/dist/patches/ is uClinux-dist-20080808-20090112.patch.gz, same as on http://sourceforge.net/project/showfiles.php?group_id=240583package_id= 292947 both contain a patched 2.6.26 kernel now, also under http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/ I find linux-2.6.26-uc0.patch.gz as the latest patch. In one of the recent postings here I saw it mentioned that Linus has a -uc0 branch in addition to mainline. No, thats not the case. Linus has no separate branches for uClinux. I have patches that I version -uc0, -uc1, etc. But I generate those, not Linus. They are for testing out upcoming changes that I plan to send to Linus. And from another email I concluded that __uClinux__ is a conditional that surround nommu-isms in the kernel source but grep -r __uClinux__ * gives me nothing in the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git. No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. I would encourage you to base anything non-MMU specific (not architecture specific) on this. The define __uClinux__ is a gcc definition used by compilers generated for uclinux. One of my colleagues says that uClinux is fully integrated in the mainline kernel now but seeing the patches for 2.6.26 and not finding anything with my grep confused me a bit and just trying with 2.6.28 or newer is several days of work. non-MMU support is fully integrated into the kernel (has been in all 2.6 series kernels). Could someone please tell me which kernel is the newest that I can use to put our architecture code in and run the uClinux userland code and libs underneath? I would use 2.6.28, if you are serious about pushing for main line inclusion. I will release a 2.6.28-uc0 in a couple of weeks time. But there is no reason to wait for that. I only checked the FAQs on uClinux and uCdot and I am reading uClinux-dev since about a month. If there is a better source of information I would be happy with any kind of: read this mailing archive / website kind of answer. They are about the best really... Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ 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] newest possible kernel version for trunk of uClinux-dist?
I can clarify one thing - the code on Source Forge is identical to what is on uclinux.org.It is preferred that downloads be done from Source Forge, as it's sole purpose is to unload uclinux.org. If any issues are found with the Source Forge files, please post here, as I monitor this list and will correct any issues with the Source Forge files. Jim On Wed, Jan 21, 2009 at 8:34 PM, Rainer Keller rkel...@ubicom.com wrote: Hi All, My company is porting uClinux to our processor architecture that is used in several routers and some digital picture frames on the market. We started with the 20080808 distribution (2.6.25-uc0 kernel) and have a kernel up and are adding drivers and user mode code currently. Our architecture has nommu but SMP support, gpios and other things that we see are in great flux in the mainline kernel. The latest patch in http://www.uclinux.org/pub/uClinux/dist/patches/ is uClinux-dist-20080808-20090112.patch.gz, same as on http://sourceforge.net/project/showfiles.php?group_id=240583package_id= 292947 both contain a patched 2.6.26 kernel now, also under http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/ I find linux-2.6.26-uc0.patch.gz as the latest patch. In one of the recent postings here I saw it mentioned that Linus has a -uc0 branch in addition to mainline. And from another email I concluded that __uClinux__ is a conditional that surround nommu-isms in the kernel source but grep -r __uClinux__ * gives me nothing in the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git. One of my colleagues says that uClinux is fully integrated in the mainline kernel now but seeing the patches for 2.6.26 and not finding anything with my grep confused me a bit and just trying with 2.6.28 or newer is several days of work. Could someone please tell me which kernel is the newest that I can use to put our architecture code in and run the uClinux userland code and libs underneath? I only checked the FAQs on uClinux and uCdot and I am reading uClinux-dev since about a month. If there is a better source of information I would be happy with any kind of: read this mailing archive / website kind of answer. - Rainer ___ 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
