Re: prevalence of C++ in embedded linux?
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. 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
embedded rootfs utility
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. For those of you who are interested, it does the following: builds a first stage debootstrap directory using a dist/mirror of your choice, and then tweaks it so you can boot it natively to be able to run the second stage debootstrap scripts. Yes, you can do all these things manually, however, this does it all for you in a few minutes (with reasonable defaults for available options). The only annoying bit is it must be run as root, as it needs to be able to set file permissions/ownerships and such. For example (as root): # elbs rootfs --arch mips --baud 19200 --dist etch /nfs/myrootfs I: Building rootfs in /nfs/myrootfs I: Installing etch/mips from http://http.us.debian.org/debian I: debootstrap succeeded I: MAKEDEV in /nfs/myrootfs/dev I: create /nfs/myrootfs/etc/group Boot your target with /nfs/myrootfs as your rootfs, then run the finish script on the target The directory /nfs/myrootfs will now contain a stage-one (unconfigured) debootstrap installation of arch mips from debian/etch, modified to allow you to connect to a serial console ttyS0 at 19200 baud (as specified on the command line above). You then need to boot your target using this rootfs and run the finish.sh script which will complete the installation. # sh /finish.sh You should now have a fully configured rootfs for your target which is capable of native compiling (amongst other things). You can find elbs at http://debian.websterwood.com/elbs/ The help text can be found here http://debian.websterwood.com/elbs/elbs-rootfs.html Alternatively, for you Debian/Ubuntu users, add these to your sources.list and # apt-get install elbs deb http://debian.websterwood.com/ sid main or deb http://debian.websterwood.com/ hardy main For those of you at OLS2008 who attended the MIPS or CELF BoFs, this is the utility I promised I would release. I hope some of you find this helpful. Yes, I know this is, in principal, very similar to what emdebian's emsandbox does. In my defense, I wasn't aware of emsandbox when I wrote this, and whereas emsandbox uses special emdebian packages, elbs-rootfs uses vanilla debian packages which is what I chose to use on the project that kicked this all off. I'll be adding more to this as I get to it. Bug reports, feature requests, and patches welcomed. -- 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: prevalence of C++ in embedded linux?
If you're embedded device has a window system, than a language like C++ is fine...But... To extend on this quote (by Stroustrup): "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.". 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 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). 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...] marty > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-embedded- > [EMAIL PROTECTED] On Behalf Of Bernd Petrovitsch > Sent: Tuesday, July 29, 2008 5:47 AM > To: Alexander Neundorf > Cc: linux-embedded@vger.kernel.org > Subject: Re: prevalence of C++ in embedded linux? > > On Tue, 2008-07-29 at 10:58 +0200, Alexander Neundorf wrote: > > On Tuesday 29 July 2008 10:20:12 you wrote: > > > On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote: > > ... > > > Yes, one *can* use the above features and get small features. But > most > > > people simply can't - if only that they use some tool/lib written in > C++ > > > (and coming from the "normal" world) which simply uses them without > > > thinking about space and wonder why the device won't run with "only" > > > 128MB flash and run in 16MB RAM. > > > > Well, if somebody carelessly uses general purpose apps/libs in a tiny > embedded > > project he will have problems, no matter if it's C or C++. > > Of course. > But it is IMHO much more easier and seductive to use the code bloating > features with C++ - especially if you don't know what to do and do not > realize (until it's too late). > > Evey other potential customer asks about C++ on an embedded device. And > if you say "yes" they *expect* to use all that g++ allows. Period. > > Getting exceptions and restrictions to the use of C++ (including any 3rd > party software - known and unknown) in an offer? > Please be serious. > > Discussing afterwards that these templates are a very bad idea (and need > to be converted to "a pure virtual class and lots of classes" to avoid > code bloat and that it will cost a few man-weeks and calendar time)? > I can hear it already: "But you said that C++ is OK and this is plain C > ++". > > > > BTW why should I use C++ if I don't use any "fancy features"? > > > > If you just skip RTTI and exceptions you have enough fancy features > left :-) > > Hmm, does g++ has options to completely disabled these (and other) > "fancy features"? At least one could check 3rd party software more > easily if they actually use that. > > Multiple inheritance[0] is in my experience not really necessary (if > ever used). > I already have "Safe C" with gcc anyways (if I want and enable some > warnings;-). > OO design is a question of design and not of the implementation > language. I can't see much difference between > - declaring a class and using a method or > - declaring a struct and use a pointer to an instance as the first > parameter in several functions. > Leaves operator/function overloading and default values for parameters. > But it adds usually libstdc++.so > > > Just know what you're doing if you're using templates and multiple > > ACK. But what is with the other 90%? > > > inheritance, there is no problem with them. Templates are so much > better than > > macros, and if used carefully they don't bloat the code size. > > Don't get me wrong - I'm not religiously against C++ in anyway. > It's just that you *really* need to know what you do and that implies > IMHO for C++ that you must know how templates work/are implemente
Re: [patch 2/4] Configure out file locking features
Matt Mackall wrote: > The typical embedded NFS-based devices are NAS servers and media players > and are going to be more concerned about things like page cache > balancing. Oh, those. It would be really annoying to buy a home NAS and find it doesn't support NFS locks or SMB oplocks. NASes are vaguely useful for more than one computer in the house at the same time. That said, I bought a big, expensive one, found it far too slow for my needs, send it back for a refund and bought a portable cheap USB disk which had *so* much higher performance. The convenience of serving multiple machines just wasn't worth the lousy performance. -- 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: [patch 2/4] Configure out file locking features
On Tue, 2008-07-29 at 12:17 -0600, Matthew Wilcox wrote: > On Tue, Jul 29, 2008 at 05:45:22PM +0200, Thomas Petazzoni wrote: > > This patch adds the CONFIG_FILE_LOCKING option which allows to remove > > support for advisory locks. With this patch enabled, the flock() > > system call, the F_GETLK, F_SETLK and F_SETLKW operations of fcntl() > > and NFS support are disabled. These features are not necessarly needed > > on embedded systems. It allows to save ~11 Kb of kernel code and data: > > > >textdata bss dec hex filename > > 1125436 118764 212992 1457192 163c28 vmlinux.old > > 1114299 118564 212992 1445855 160fdf vmlinux > > -11137-200 0 -11337 -2C49 +/- > > > > This patch has originally been written by Matt Mackall > > <[EMAIL PROTECTED]>, and is part of the Linux Tiny project. > > > > Signed-off-by: Thomas Petazzoni <[EMAIL PROTECTED]> > > In principle, I think this is a great idea. > > > config NFS_FS > > tristate "NFS client support" > > - depends on INET > > + depends on INET && FILE_LOCKING > > select LOCKD > > select SUNRPC > > select NFS_ACL_SUPPORT if NFS_V3_ACL > > I think this part is a little lazy. It should be possible to support > NFS without file locking. I suspect that's really not in-scope for the > linux-tiny tree as currently envisaged with the focus on embedded > devices that probably don't use NFS anyway. Do we want to care about > the situation of a machine with fixed workload, that doesn't need file > locking, but does use NFS? I would lean towards no, but if someone comes along who cares, they're welcome to try it. This stuff all has to strike a balance between savings and effort/complexity/maintainability, so any time the submitter is too lazy to cover a less common use case, it's probably a good sign they're approaching that tipping point. On the other hand, if you think it's trivial to do a locking-ectomy on NFS, I'd be happy to see it. The typical embedded NFS-based devices are NAS servers and media players and are going to be more concerned about things like page cache balancing. -- Mathematics is the supreme nostalgia of our time. -- 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
On Tue, Jul 29, 2008 at 05:45:22PM +0200, Thomas Petazzoni wrote: > This patch adds the CONFIG_FILE_LOCKING option which allows to remove > support for advisory locks. With this patch enabled, the flock() > system call, the F_GETLK, F_SETLK and F_SETLKW operations of fcntl() > and NFS support are disabled. These features are not necessarly needed > on embedded systems. It allows to save ~11 Kb of kernel code and data: > >text data bss dec hex filename > 1125436118764 212992 1457192 163c28 vmlinux.old > 1114299118564 212992 1445855 160fdf vmlinux > -11137-200 0 -11337 -2C49 +/- > > This patch has originally been written by Matt Mackall > <[EMAIL PROTECTED]>, and is part of the Linux Tiny project. > > Signed-off-by: Thomas Petazzoni <[EMAIL PROTECTED]> In principle, I think this is a great idea. > config NFS_FS > tristate "NFS client support" > - depends on INET > + depends on INET && FILE_LOCKING > select LOCKD > select SUNRPC > select NFS_ACL_SUPPORT if NFS_V3_ACL I think this part is a little lazy. It should be possible to support NFS without file locking. I suspect that's really not in-scope for the linux-tiny tree as currently envisaged with the focus on embedded devices that probably don't use NFS anyway. Do we want to care about the situation of a machine with fixed workload, that doesn't need file locking, but does use NFS? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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 1/4] Configure out AIO support
On Tue, 2008-07-29 at 17:45 +0200, Thomas Petazzoni wrote: > plain text document attachment (configure-out-aio-support) > This patchs adds the CONFIG_AIO option which allows to remove support > for asynchronous I/O operations, that are not necessarly used by > applications, particularly on embedded devices. As this is a > size-reduction option, it depends on CONFIG_EMBEDDED. It allows to > save ~7 kilobytes of kernel code/data: > >text data bss dec hex filename > 1115067119180 217088 1451335 162547 vmlinux > 1108025119048 217088 1444161 160941 vmlinux.new > -7042-132 0 -7174 -1C06 +/- > > This patch has been originally written by Matt Mackall > <[EMAIL PROTECTED]>, and is part of the Linux Tiny project. > > Signed-off-by: Thomas Petazzoni <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] These all look good to me, naturally. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. -- 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?
2008/7/29 Bart Van Assche <[EMAIL PROTECTED]>: > On Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli > <[EMAIL PROTECTED]> wrote: >> Like Linus Torvals said "...C++ is an horrible language" :) > > Some C++ language features are indeed not very elegant from a > language-theoretic standpoint. But that doesn't matter when writing > embedded software -- what matters is that C++ allows to make source > code a lot more readable than the C programming language. And if you > don't like the overhead introduced by features like exceptions or > RTTI, you can still pass -fno-exceptions -fno-rtti to gcc. IMHO choosing a language is like choosing any other tool to get a job done. I wouldn't use a screwdriver to bang in a nail (um, actually, I have and it ruined my screwdriver so I won't do it again) and same goes for programming languages. For low-level programming, such as kernels and device drivers, C and some assembly is probably the right choice in most cases. That is not to say that C++ or any other language could not be used. I know of at least one OS written almost entirely in C++ (drivers were objects that could be passed between devices to help them communicate with each other, very neat). Looking at something like graphics programming C++ makes a lot more sense. It is natural to think of a window inheriting properties from the widgets that implement it's functionality. Qt and wxWidgets are good examples, or Swing for Java. But of course Motif and GTK are written in C and work perfectly well too. I'm not sure how easy it is to "inherit" in GTK but vaguely remember it was not exactly trivial in Motif. To me at least C++ makes more sense here. Scripts also have a very important role. I am probably in the minority when I say that I like Tcl, but used for it's original purpose it is a very useful language. There are many cases where I would chose to use Tcl or Perl or sh scripts rather than C, C++ or Java. The resources of the target system are also important. Many "embedded" systems these days are as powerful, if not more so, than my laptop. For these systems you have a lot of freedom. For others there may be limited RAM, disk space or other resources. I am often asked about removing Perl from the systems my customers use because of the large disk footprint. So let's not be too hasty to label any language as bad. Each was developed to address a need. Trying to use the wrong language for a particular purpose is the bad thing. Rich -- 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 Tue, 2008-07-29 at 10:58 +0200, Alexander Neundorf wrote: > On Tuesday 29 July 2008 10:20:12 you wrote: > > On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote: > ... > > Yes, one *can* use the above features and get small features. But most > > people simply can't - if only that they use some tool/lib written in C++ > > (and coming from the "normal" world) which simply uses them without > > thinking about space and wonder why the device won't run with "only" > > 128MB flash and run in 16MB RAM. > > Well, if somebody carelessly uses general purpose apps/libs in a tiny > embedded > project he will have problems, no matter if it's C or C++. Of course. But it is IMHO much more easier and seductive to use the code bloating features with C++ - especially if you don't know what to do and do not realize (until it's too late). Evey other potential customer asks about C++ on an embedded device. And if you say "yes" they *expect* to use all that g++ allows. Period. Getting exceptions and restrictions to the use of C++ (including any 3rd party software - known and unknown) in an offer? Please be serious. Discussing afterwards that these templates are a very bad idea (and need to be converted to "a pure virtual class and lots of classes" to avoid code bloat and that it will cost a few man-weeks and calendar time)? I can hear it already: "But you said that C++ is OK and this is plain C ++". > > BTW why should I use C++ if I don't use any "fancy features"? > > If you just skip RTTI and exceptions you have enough fancy features left :-) Hmm, does g++ has options to completely disabled these (and other) "fancy features"? At least one could check 3rd party software more easily if they actually use that. Multiple inheritance[0] is in my experience not really necessary (if ever used). I already have "Safe C" with gcc anyways (if I want and enable some warnings;-). OO design is a question of design and not of the implementation language. I can't see much difference between - declaring a class and using a method or - declaring a struct and use a pointer to an instance as the first parameter in several functions. Leaves operator/function overloading and default values for parameters. But it adds usually libstdc++.so > Just know what you're doing if you're using templates and multiple ACK. But what is with the other 90%? > inheritance, there is no problem with them. Templates are so much better than > macros, and if used carefully they don't bloat the code size. Don't get me wrong - I'm not religiously against C++ in anyway. It's just that you *really* need to know what you do and that implies IMHO for C++ that you must know how templates work/are implemented. Similar for exceptions (and no, using exceptions usually doesn't save space anywhere - at least not if your calling depth is < 100). if you use them (or use a library that uses them). And may need or may not need libstdc++.so - an additional piece of code using space. Of course, if you have 1GB of flash and 256M RAM, who cares. But most of the devices I see are not that "fat". In short: It is far from easy to *not* shoot yourself in the foot with C++. At least compared to plain C. Bernd [0]: Yes, I know what's the difference between normal and virtual inheritance. -- 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?
On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote: > On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote: > > Robert P. J. Day ha scritto: > > > just curious -- how many folks are working in C++ in their embedded > > > linux work? Not if it's in anyway avoidable. [] > > Like Linus Torvals said "...C++ is an horrible language" :) > > If you avoid RTTI and exceptions and if you are handle templates and multiple > inheritance carefully I see nothing which speaks against using it for > embedded and real-time software. That's the main reason for *not* using C++ in the embedded world in the first place. Tell people that they may use C++ and see them happy. Then tell them that you better not use templates, RTTI, exceptions and multiple inheritance if you want to boot from small space. Yes, one *can* use the above features and get small features. But most people simply can't - if only that they use some tool/lib written in C++ (and coming from the "normal" world) which simply uses them without thinking about space and wonder why the device won't run with "only" 128MB flash and run in 16MB RAM. BTW why should I use C++ if I don't use any "fancy features"? 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?
On Tuesday 29 July 2008 10:20:12 you wrote: > On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote: ... > Yes, one *can* use the above features and get small features. But most > people simply can't - if only that they use some tool/lib written in C++ > (and coming from the "normal" world) which simply uses them without > thinking about space and wonder why the device won't run with "only" > 128MB flash and run in 16MB RAM. Well, if somebody carelessly uses general purpose apps/libs in a tiny embedded project he will have problems, no matter if it's C or C++. > BTW why should I use C++ if I don't use any "fancy features"? If you just skip RTTI and exceptions you have enough fancy features left :-) Just know what you're doing if you're using templates and multiple inheritance, there is no problem with them. Templates are so much better than macros, and if used carefully they don't bloat the code size. Alex -- 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 Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli <[EMAIL PROTECTED]> wrote: > Like Linus Torvals said "...C++ is an horrible language" :) Some C++ language features are indeed not very elegant from a language-theoretic standpoint. But that doesn't matter when writing embedded software -- what matters is that C++ allows to make source code a lot more readable than the C programming language. And if you don't like the overhead introduced by features like exceptions or RTTI, you can still pass -fno-exceptions -fno-rtti to gcc. 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?
Bernd Petrovitsch ha scritto: On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote: On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote: Robert P. J. Day ha scritto: just curious -- how many folks are working in C++ in their embedded linux work? Not if it's in anyway avoidable. [] Like Linus Torvals said "...C++ is an horrible language" :) If you avoid RTTI and exceptions and if you are handle templates and multiple inheritance carefully I see nothing which speaks against using it for embedded and real-time software. That's the main reason for *not* using C++ in the embedded world in the first place. Tell people that they may use C++ and see them happy. Then tell them that you better not use templates, RTTI, exceptions and multiple inheritance if you want to boot from small space. Yes, one *can* use the above features and get small features. But most people simply can't - if only that they use some tool/lib written in C++ (and coming from the "normal" world) which simply uses them without thinking about space and wonder why the device won't run with "only" 128MB flash and run in 16MB RAM. BTW why should I use C++ if I don't use any "fancy features"? Bernd I quite agree with you -- 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: prevalence of C++ in embedded linux?
On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote: > Robert P. J. Day ha scritto: > > just curious -- how many folks are working in C++ in their embedded > > linux work? > > > > rday > > -- > > > > 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 > > Like Linus Torvals said "...C++ is an horrible language" :) If you avoid RTTI and exceptions and if you are handle templates and multiple inheritance carefully I see nothing which speaks against using it for embedded and real-time software. e.g. the kernel eCos is implemented in C++. Alex -- 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?
Robert P. J. Day ha scritto: just curious -- how many folks are working in C++ in their embedded linux work? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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 Like Linus Torvals said "...C++ is an horrible language" :) -- 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
