Re: [patch 2/4] Configure out file locking features
Hello Thomas, Thomas Petazzoni wrote: > Le Wed, 30 Jul 2008 17:27:54 +0300, > Adrian Bunk <[EMAIL PROTECTED]> a écrit : > > > It seems the emails containing the patches never made it to the vger > > lists, which makes it a bit hard to comment on them. > > Yes, they didn't make it to the lists, for some reason. Maybe it's > because I sent them using "quilt mail --send", which uses my local > exim4 mail server, and for some reason, vger doesn't like that kind of > e-mails. However, my exim4 is configured to sent the e-mails through by > ISP SMTP. From my exim4 mainlog: > > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg => [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> linux-embedded@vger.kernel.org > R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost > T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* > 2008-07-29 17:47:57 1KNrQS-0007kt-Kg Completed > > So from my side, everything seemed to work well. Does anybody has a > clue ? Don't know if this is the problem, but I had problems getting mails through some time ago, too. For me the problem was that the source address was [EMAIL PROTECTED] and vger.kernel.org didn't want to take these because the host name had no DNS entry. I fixed that by rewriting the From line in outgoing mails on my host. I'm using postfix (from Debian) so I had to add an entry to /etc/postfix/sender_canonical. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Configure out file locking features
Le Wed, 30 Jul 2008 17:27:54 +0300, Adrian Bunk <[EMAIL PROTECTED]> a écrit : > It seems the emails containing the patches never made it to the vger > lists, which makes it a bit hard to comment on them. Yes, they didn't make it to the lists, for some reason. Maybe it's because I sent them using "quilt mail --send", which uses my local exim4 mail server, and for some reason, vger doesn't like that kind of e-mails. However, my exim4 is configured to sent the e-mails through by ISP SMTP. From my exim4 mainlog: 2008-07-29 17:47:57 1KNrQS-0007kt-Kg => [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> linux-embedded@vger.kernel.org R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4]* 2008-07-29 17:47:57 1KNrQS-0007kt-Kg Completed So from my side, everything seemed to work well. Does anybody has a clue ? > Thomas, can you try to figure out what went wrong and resend them > then? I will send them again through my normal MUA, using quilt mail --mbox. Hopefully it'll work. Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: PGP signature
Re: embedded rootfs utility
Marco Stornelli wrote: > > On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote: >> A quick announcement of the release of elbs, or the "Embedded Linux >> Build System" (it seemed like a good name at the time I started writing >> it...) So far it's just a few utilities that I wrote to make a few of >> my own projects easier. >> >> However, most notably it contains a utility called "elbs-rootfs" which >> makes it easy to create an embedded rootfs for any architecture >> supported by the Debian projecy (or Ubuntu Linux). The idea is to get a >> rootfs up and working quickly via nfs (or a flash drive) which allows >> you to install any debian package and/or to do native development. This >> is (not yet) meant as a tool to make your final rootfs fit on a small >> flash partition. >> > > Very interesting, where can I found it? Can you give me a site to > download it? > It's listed near the bottom of the announcement. > You can find elbs at http://debian.websterwood.com/elbs/ Enjoy. Behan -- Behan Webster [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: embedded rootfs utility
On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote: A quick announcement of the release of elbs, or the "Embedded Linux Build System" (it seemed like a good name at the time I started writing it...) So far it's just a few utilities that I wrote to make a few of my own projects easier. However, most notably it contains a utility called "elbs-rootfs" which makes it easy to create an embedded rootfs for any architecture supported by the Debian projecy (or Ubuntu Linux). The idea is to get a rootfs up and working quickly via nfs (or a flash drive) which allows you to install any debian package and/or to do native development. This is (not yet) meant as a tool to make your final rootfs fit on a small flash partition. Very interesting, where can I found it? Can you give me a site to download it? -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Configure out file locking features
It seems the emails containing the patches never made it to the vger lists, which makes it a bit hard to comment on them. Thomas, can you try to figure out what went wrong and resend them then? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: embedded rootfs utility
On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote: > A quick announcement of the release of elbs, or the "Embedded Linux > Build System" (it seemed like a good name at the time I started writing > it...) So far it's just a few utilities that I wrote to make a few of > my own projects easier. > > However, most notably it contains a utility called "elbs-rootfs" which > makes it easy to create an embedded rootfs for any architecture > supported by the Debian projecy (or Ubuntu Linux). The idea is to get a > rootfs up and working quickly via nfs (or a flash drive) which allows > you to install any debian package and/or to do native development. This > is (not yet) meant as a tool to make your final rootfs fit on a small > flash partition. Hey Behan, thanks for posting this. For anybody looking at this tool, I can attest to it's usefulness. For my work it has simplified getting a full development environment setup for embedded targets. What mailing list should be used for any discussion/patches on this tool? Cheers, g. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AT91 kernel programming documentation ?
On Wed, Jul 30, 2008 at 03:53:19PM +0200, Stefan Schoenleitner wrote: > I'm looking for some good documentation concerning AT91 Linux kernel > development. Currently I have a Olimex AT91SAM9260 development board > which is supported by the at91 patch set. The base functionality is supported in the Linux mainline. > Now I would like to add different hardware to the board and write some > kernel code for it. What kind of hardware? > Unfortunately, there doesn't seem to be a lot of documentation. At > the moment I'm reading mach-at91 related source code and trying to > find out how things work. I assume you've already bought a copy of the Rubini Device Driver book? > Specificly, I would like to know how the different SoC devices can be > accessed and used, how I can do port multiplexing, how I can tell the > kernel which hardware is attached to where and so on. Check arch/arm/mach-at91/*. It very much depends on what you want to do. Documentation/drivermodel/ might also be worth a look. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
On Wed, 2008-07-30 at 14:07 +0100, Jamie Lokier wrote: > Bernd Petrovitsch wrote: > > If "GOLD" is as old and flexible (and portable?) as binutils, > > The author says it will only work with ELF, and he does not > intend to add support for all the other things binutils does. Well, supporting 80% of the deployed systems requires probably only 20% of the code;-) But then it won't really replace binutils. And if, some quirky hardware/systems have a problem . > > gcc and/or other huge software maintained to death, it is probably > > similar complex and odd. If people take a > 10 year old tool and > > rewrite it from scratch, I would assume that design is better. > > Only true if the cruft is no longer relevant. If the cruft is > intrinsic to the problem, e.g. supporting umpteen quirky architectures > implies umpteen quirks of cruft, then it'll be in the new design. Yes, but one can make a better design in always knowing/planning to have hooks here and there and everywhere. > Btw, gcc and binutils are more like 30 years old :-) That doesn't make it better;-) I was too lazy to search for more exact numbers. > > And I can't see any direct dependence on the used programming > > language(s) if one compares running code and what is left of "design" > > after years of design extensions, changes, enhancements, etc. to a new > > design from scratch from the lessons learned (hopefully) from the former > > one. > > Some programming languages allow you to express a problem concisely > and clearly, and some don't. That clarity then affects whether an And if C is too low-level, one abstracts with functions etc. I call that "design" - independent if the design existed before the source or if the design evolved over years with the software And yes, at first it is enough to add a parameter and/or function here and there without breaking implicit or explicit assumptions. But at one point from a larger view, the "design problems" will be obvious and one can either solve them (investing time/money for effectively no real gain in features and/or functionality, just only cleanups or refactoring of parts or whatever one wants to call it) or lives on with patching/maintaining the software to death. > evolving design becomes loaded with implementation cruft or not - and > you can't always tell the difference. Yes. And over the years and decades, the implementation evolves with the problems - new and existing ones. If the design doesn't involve - which IMHO implies refactoring of existing, tested and working code(!) possible breaking it - you have at some point such a mess that each "trivial" enhancement takes age (and breaks again somewhere else something). > Most languages are well-matched to different problem domains. Maybe. IMHO these differences are almost nothing compared to the below point: > Binutils and bfd look very crufty, but I think it's hard to tell how > much of that is due to the implementation language and implementation, > or the design and requirements, and how much would exist in any > implementation on any language. IMHO it's (mostly) independent of the implementation language: If changes in design are not completed (including removal of old deprecated stuff or at least push it in peripheral places where nobody cares;-) in the implementation (for whatever reason - no one does it, no one wants to pay it, one wants to support every API indefinitely, ), it will lead more sooner than later to unmaintanable crufty software. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AT91 kernel programming documentation ?
Hi, I'm looking for some good documentation concerning AT91 Linux kernel development. Currently I have a Olimex AT91SAM9260 development board which is supported by the at91 patch set. Now I would like to add different hardware to the board and write some kernel code for it. Unfortunately, there doesn't seem to be a lot of documentation. At the moment I'm reading mach-at91 related source code and trying to find out how things work. Specificly, I would like to know how the different SoC devices can be accessed and used, how I can do port multiplexing, how I can tell the kernel which hardware is attached to where and so on. Can you guys suggest any documentation ? -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
Bernd Petrovitsch wrote: > If "GOLD" is as old and flexible (and portable?) as binutils, The author says it will only work with ELF, and he does not intend to add support for all the other things binutils does. > gcc and/or other huge software maintained to death, it is probably > similar complex and odd. If people take a > 10 year old tool and > rewrite it from scratch, I would assume that design is better. Only true if the cruft is no longer relevant. If the cruft is intrinsic to the problem, e.g. supporting umpteen quirky architectures implies umpteen quirks of cruft, then it'll be in the new design. Btw, gcc and binutils are more like 30 years old :-) > And I can't see any direct dependence on the used programming > language(s) if one compares running code and what is left of "design" > after years of design extensions, changes, enhancements, etc. to a new > design from scratch from the lessons learned (hopefully) from the former > one. Some programming languages allow you to express a problem concisely and clearly, and some don't. That clarity then affects whether an evolving design becomes loaded with implementation cruft or not - and you can't always tell the difference. Most languages are well-matched to different problem domains. Binutils and bfd look very crufty, but I think it's hard to tell how much of that is due to the implementation language and implementation, or the design and requirements, and how much would exist in any implementation on any language. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
Jamie Lokier <[EMAIL PROTECTED]> wrote: > The GNU Binutils requirement was to target lots of different object > formats, and architectures, allow different ones to be interconverted > and linked together, and to run on lots of platforms. The Linux kernel also meets those requirements (the ones that are relevant for a kernel that is.) > Given those constraints, probably C was the only option at the time, > and BFD's interface, although ugly and difficult to work with, does > reflect the abstractions of different object formats and architectures > moderately well IMHO. Well, I guess it does work moderately well once you get used to it. But there are lots of hidden dependencies all over the place. I still haven't figured out how to un-break the debugging information after relaxing, for example. But what I disagree with is that these problems are somehow a symptom of using C as the implementation language. They're a symptom of bad design decisions IMO. > It's tough to make a nice design that meets those requirements. Absolutely. But does using C++ as an implementation language really make it any easier? > It's unfortunate that BFD is so hard to work with that people resort > to post-processing tools and other hacks, instead of enjoying adding > new format support to it. > > For all it's faults working with it, the tools themselves are very > versatile and useful compared with most equivalents. Agreed. I definitely prefer using the GNU tools over the alternatives I've seen. But that doesn't mean they can't be improved further. > If you have clear improvements that would simplify GOLD (without > breaking it or requirements you might not be aware of), the author may > be quite receptive to them. He seems keen on the code being of high > quality, and he's quite experienced at working on "open" projects with > many contributors. Yeah, I suppose I should put my money where my mouth is and offer some constructive suggestions. Right now I'm waiting for someone to get the necessary paperwork in place so that we can work as closely with the GNU community as we do with the Linux kernel and several other communities. Off the top of my head, after looking just at the target interface, I'd really like to see * A few better abstractions so that the target relocation hooks don't need a gazillion parameters. * Some way to spread the target implementation across a few more files/classes so that we don't end up with a single several-thousand-lines file for each architecture. A subdir for each arch would be nice. Currently, it looks like the target interface is headed down the same road as libbfd, and that means the code will be just as unmanageable in a few years. I'm also curious about what things will look like once support for complicated things like --relax and --gc-sections is added... But I guess complaining about it here won't do much good. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
On Wed, 2008-07-30 at 13:04 +0200, Bart Van Assche wrote: [...] > I don't know whether C++ is intrinsic to GOLD's linking superiority. > The reason I cited the GOLD project is because of the programming > style of the GOLD source code. A quote from > http://lwn.net/Articles/274859/, about the GOLD source code: > > I looked through the gold sources a bit. I wish everything in the GNU > toolchain were written this way. It is very clean code, nicely > commented, and easy to follow. It shows pretty clearly, I think, the > ways in which C++ can be better than C when it is used well. If "GOLD" is as old and flexible (and portable?) as binutils, gcc and/or other huge software maintained to death, it is probably similar complex and odd. If people take a > 10 year old tool and rewrite it from scratch, I would assume that design is better. And I can't see any direct dependence on the used programming language(s) if one compares running code and what is left of "design" after years of design extensions, changes, enhancements, etc. to a new design from scratch from the lessons learned (hopefully) from the former one. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
Haavard Skinnemoen wrote: > "Bart Van Assche" <[EMAIL PROTECTED]> wrote: > > I looked through the gold sources a bit. I wish everything in the GNU > > toolchain were written this way. It is very clean code, nicely > > commented, and easy to follow. It shows pretty clearly, I think, the > > ways in which C++ can be better than C when it is used well. > > I guess he never looked at the target interface... > > [snip virtual method with loads of arguments which looks like binutils] > > I can't wait to implement avr32 support for that monster...I thoroughly > hate working on libbfd, and it looks like gold has made many of the > same stupid decisions on the interface level. > Just shows that using C++ doesn't fix a design that is broken to begin > with. The GNU Binutils requirement was to target lots of different object formats, and architectures, allow different ones to be interconverted and linked together, and to run on lots of platforms. Given those constraints, probably C was the only option at the time, and BFD's interface, although ugly and difficult to work with, does reflect the abstractions of different object formats and architectures moderately well IMHO. It's tough to make a nice design that meets those requirements. It's unfortunate that BFD is so hard to work with that people resort to post-processing tools and other hacks, instead of enjoying adding new format support to it. For all it's faults working with it, the tools themselves are very versatile and useful compared with most equivalents. If you have clear improvements that would simplify GOLD (without breaking it or requirements you might not be aware of), the author may be quite receptive to them. He seems keen on the code being of high quality, and he's quite experienced at working on "open" projects with many contributors. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
"Bart Van Assche" <[EMAIL PROTECTED]> wrote: > I looked through the gold sources a bit. I wish everything in the GNU > toolchain were written this way. It is very clean code, nicely > commented, and easy to follow. It shows pretty clearly, I think, the > ways in which C++ can be better than C when it is used well. I guess he never looked at the target interface... > // Relocate a section during a relocatable link. The parameters are > // like relocate_section, with additional parameters for the view of > // the output reloc section. > virtual void > relocate_for_relocatable(const Relocate_info*, >unsigned int sh_type, >const unsigned char* prelocs, >size_t reloc_count, >Output_section* output_section, >off_t offset_in_output_section, >const Relocatable_relocs*, >unsigned char* view, >typename elfcpp::Elf_types::Elf_Addr > view_address, >section_size_type view_size, >unsigned char* reloc_view, >section_size_type reloc_view_size) = 0; I can't wait to implement avr32 support for that monster...I thoroughly hate working on libbfd, and it looks like gold has made many of the same stupid decisions on the interface level. Just shows that using C++ doesn't fix a design that is broken to begin with. Oh, and I think "relax.cc" is missing ;-) Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
On Wed, Jul 30, 2008 at 12:25 PM, Jamie Lokier <[EMAIL PROTECTED]> wrote: > Bart Van Assche wrote: >> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin >> <[EMAIL PROTECTED]> wrote: >> > If you're embedded device has a window system, than a language like C++ >> > is fine...But... >> >> C++ is suited for much more than just windowing systems. A good >> example is the GOLD project, a linker for ELF files. GOLD is a rewrite >> of the GNU linker (ld). See also >> http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html. > > Is C++ intrinsic to GOLD's linking superiority over ld? Or was it > chosen because the author fancied using it? (I don't know). I don't know whether C++ is intrinsic to GOLD's linking superiority. The reason I cited the GOLD project is because of the programming style of the GOLD source code. A quote from http://lwn.net/Articles/274859/, about the GOLD source code: I looked through the gold sources a bit. I wish everything in the GNU toolchain were written this way. It is very clean code, nicely commented, and easy to follow. It shows pretty clearly, I think, the ways in which C++ can be better than C when it is used well. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
Bart Van Assche wrote: > On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin > <[EMAIL PROTECTED]> wrote: > > If you're embedded device has a window system, than a language like C++ > > is fine...But... > > C++ is suited for much more than just windowing systems. A good > example is the GOLD project, a linker for ELF files. GOLD is a rewrite > of the GNU linker (ld). See also > http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html. Is C++ intrinsic to GOLD's linking superiority over ld? Or was it chosen because the author fancied using it? (I don't know). There's been a resistance to using C++ in GNU programming tools generally for a long time - see GCC which only recently switched to ANSI C. That's because they want the tools to run on lots of platforms, and C++ templates in particular haven't been standardly implemented until the last few years, and probably still aren't on some platforms that they'd like to run GNU tools on. So using C++ in GOLD was a bit of a bold decision :-) What I can't help noticing is that GOLD, while superior for linking straight GNU/Linux applications due to better algorithms, and extremely knowledgable author etc. - it explicitly does not support anything but ELF. It doesn't support the zillions of linker capabilities of GNU binutils ld, and the author says he doesn't intend it to. So it won't ever be suitable for linking some embedded targets - you'll still need to use Binutils ld/objdump or another tool, at least for the last step :-) Binutils' undoing is probably the complexity in its approach to generically supporting every kind of linkable object anywhere. That complexity is the reason we have the ugly 'elf2flt' instead of simply a backend which emits uClinux executable formats. The authors of uClinux tools found it easier to postprocess the output than to write another format backend. I don't think C++ would help a lot with that complexity if you wanted to still support lots of different formats - although another language with versatile metaprogramming might. (There's a lot to choose from). I could be wrong of course. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
Leisner, Martin wrote: > I've found you can understand spaghetti C code with some effort -- its > nearly impossible to understand spaghetti C++ code. Much professional > programming is "kitchen sink mentality" -- if there's a feature, use it. > > I find it interesting K&R is about 200 pages, Stroustrup is 1000+ pages. > What percentage of the 200 pages is understood by the average C > programmer versus the 1000+ pages by the average C++ programmers? > > I program by the quote by Einstein "Things should be as simple as > possible, no simpler". > > Much of the C++ code I've seen has more complicated implementation > details than the problem being solved (I'm a believer in Halstead > metrics, a lot of solutions I've seen in C++ would be much smaller in > C). Of course, that's the solutions in C++ I've seen...not all of > them Ok, but most of what you say applies the same to "generic" programming and not particularly to embedded. I.e. if you agree with your points, you won't use C++ much in general, and if you disagree and like C++ in general, then why not use it for embedded as well. > I think C++ lends itself to coming up with complicated solutions to > simple problems...(of course really good C++ is simple and > clever...but much C++ I see is poorly designed raw overcooked > spaghetti). If you think C lends itself to simple solutions, go read a Linux kernel sometime :-) > Also its very useful to have an understanding how the hardware works in > systems where memory/time is an issue (and it almost always should be an > issue). I have a good understanding of what will happen in my C > compiler > (a good algorithm in C runs rings around bad algorithms in assembler). > [nowadays, instead of processor performance, you think about cache > performance]. I doubt there's generally a good understand of time/space > of C++ features in the compiler and standard library...] Actually, the C++ standard library specification _defines_ time requirements for many of its algorithms. That's better than C - in theory. (Whether implementations follow the spec that far in practice is a different question. I can honestly say I've both read and written simple to understand, and lousy and complex C code. And the same with C++. For some problems, C++ has expressed the solution far more clearly than the equivalent C. Most notably in a video game with lots of characters and representations of physical objects, and in a GUI - very object oriented systems by nature - fit a C++ expression very well. You can imagine in a video game, time/space performance is critical. Some understanding of what goes on behind the scenes in C++ is very helpful to manage performance. I guess knowing C and machine code helps one's understanding of what a C++ compiler produces :-) Aside from time/space performance, another factor in many types of embedded programming is time to deliver the product - or how good can you make it in the fixed time available. If C helps, go for it; if C++ is familiar to you and gets you a better looking product in the same time, though, it might be prefereable for some parts. (Same for choice of libraries, tools, etc.). That really depends what kind of device you're making. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
