* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-30 12:38 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: Bart Van Assche, Leisner, Martin, Bernd Petrovitsch,
Alexander Neundorf, linux-embedded
In-Reply-To: <20080730135834.74018bf6@hskinnemo-gx745.norway.atmel.com>
Haavard Skinnemoen wrote:
> "Bart Van Assche" <bart.vanassche@gmail.com> 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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Haavard Skinnemoen @ 2008-07-30 11:58 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jamie Lokier, Leisner, Martin, Bernd Petrovitsch,
Alexander Neundorf, linux-embedded
In-Reply-To: <e2e108260807300404r65bfb2b2xfb07687601dc59da@mail.gmail.com>
"Bart Van Assche" <bart.vanassche@gmail.com> 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<size, big_endian>*,
> 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<size>::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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bart Van Assche @ 2008-07-30 11:04 UTC (permalink / raw)
To: Jamie Lokier
Cc: Leisner, Martin, Bernd Petrovitsch, Alexander Neundorf,
linux-embedded
In-Reply-To: <20080730102523.GB8992@shareable.org>
On Wed, Jul 30, 2008 at 12:25 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Bart Van Assche wrote:
>> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
>> <Martin.Leisner@xerox.com> 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.
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-30 10:25 UTC (permalink / raw)
To: Bart Van Assche
Cc: Leisner, Martin, Bernd Petrovitsch, Alexander Neundorf,
linux-embedded
In-Reply-To: <e2e108260807292146n581b655an3119be9e33af871c@mail.gmail.com>
Bart Van Assche wrote:
> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
> <Martin.Leisner@xerox.com> 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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-30 10:16 UTC (permalink / raw)
To: Leisner, Martin; +Cc: Bernd Petrovitsch, Alexander Neundorf, linux-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C092D3CF7@USA0300MS03.na.xerox.net>
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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bart Van Assche @ 2008-07-30 4:46 UTC (permalink / raw)
To: Leisner, Martin; +Cc: Bernd Petrovitsch, Alexander Neundorf, linux-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C092D3CF7@USA0300MS03.na.xerox.net>
On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
<Martin.Leisner@xerox.com> 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.
^ permalink raw reply
* embedded rootfs utility
From: Behan Webster @ 2008-07-30 2:18 UTC (permalink / raw)
To: linux-embedded
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
<snip>
I: debootstrap succeeded
I: MAKEDEV in /nfs/myrootfs/dev
<snip>
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
behanw@websterwood.com
^ permalink raw reply
* RE: prevalence of C++ in embedded linux?
From: Leisner, Martin @ 2008-07-29 20:08 UTC (permalink / raw)
To: Bernd Petrovitsch, Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <1217324838.24988.41.camel@spike.firmix.at>
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: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
> owner@vger.kernel.org] 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 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Jamie Lokier @ 2008-07-29 20:00 UTC (permalink / raw)
To: Matt Mackall
Cc: Matthew Wilcox, Thomas Petazzoni, linux-kernel, linux-embedded,
linux-fsdevel, akpm
In-Reply-To: <1217357875.15724.167.camel@calx>
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
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Matt Mackall @ 2008-07-29 18:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, linux-fsdevel,
akpm
In-Reply-To: <20080729181751.GA24924@parisc-linux.org>
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:
> >
> > text data 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
> > <mpm@selenic.com>, and is part of the Linux Tiny project.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> 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.
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Matthew Wilcox @ 2008-07-29 18:17 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-kernel, linux-embedded, linux-fsdevel, mpm, akpm
In-Reply-To: <20080729154747.872888047@free-electrons.com>
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
> 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
> <mpm@selenic.com>, and is part of the Linux Tiny project.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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."
^ permalink raw reply
* Re: [patch 1/4] Configure out AIO support
From: Matt Mackall @ 2008-07-29 16:27 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-kernel, linux-embedded, bcrl, linux-aio, akpm
In-Reply-To: <20080729154747.574989775@free-electrons.com>
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
> 1115067 119180 217088 1451335 162547 vmlinux
> 1108025 119048 217088 1444161 160941 vmlinux.new
> -7042 -132 0 -7174 -1C06 +/-
>
> This patch has been originally written by Matt Mackall
> <mpm@selenic.com>, and is part of the Linux Tiny project.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: bcrl@kvack.org
> Cc: linux-aio@kvack.org
> Cc: mpm@selenic.com
> Cc: akpm@linux-foundation.org
These all look good to me, naturally.
Signed-off-by: Matt Mackall <mpm@selenic.com>
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [patch 1/4] Configure out AIO support
From: Thomas Petazzoni @ 2008-07-29 15:45 UTC (permalink / raw)
To: linux-kernel, linux-embedded; +Cc: thomas.petazzoni, bcrl, linux-aio, mpm, akpm
In-Reply-To: <20080729154520.728594017@free-electrons.com>
[-- Attachment #1: configure-out-aio-support --]
[-- Type: text/plain, Size: 4841 bytes --]
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
1115067 119180 217088 1451335 162547 vmlinux
1108025 119048 217088 1444161 160941 vmlinux.new
-7042 -132 0 -7174 -1C06 +/-
This patch has been originally written by Matt Mackall
<mpm@selenic.com>, and is part of the Linux Tiny project.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: bcrl@kvack.org
Cc: linux-aio@kvack.org
Cc: mpm@selenic.com
Cc: akpm@linux-foundation.org
---
fs/Makefile | 3 ++-
include/linux/aio.h | 9 +++++++++
init/Kconfig | 8 ++++++++
kernel/sys_ni.c | 5 +++++
kernel/sysctl.c | 2 ++
5 files changed, 26 insertions(+), 1 deletion(-)
Index: linuxdev/fs/Makefile
===================================================================
--- linuxdev.orig/fs/Makefile
+++ linuxdev/fs/Makefile
@@ -8,7 +8,7 @@
obj-y := open.o read_write.o file_table.o super.o \
char_dev.o stat.o exec.o pipe.o namei.o fcntl.o \
ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o \
- attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
+ attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
stack.o
@@ -27,6 +27,7 @@
obj-$(CONFIG_SIGNALFD) += signalfd.o
obj-$(CONFIG_TIMERFD) += timerfd.o
obj-$(CONFIG_EVENTFD) += eventfd.o
+obj-$(CONFIG_AIO) += aio.o
obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o
nfsd-$(CONFIG_NFSD) := nfsctl.o
Index: linuxdev/include/linux/aio.h
===================================================================
--- linuxdev.orig/include/linux/aio.h
+++ linuxdev/include/linux/aio.h
@@ -204,12 +204,21 @@
/* prototypes */
extern unsigned aio_max_size;
+#ifdef CONFIG_AIO
extern ssize_t wait_on_sync_kiocb(struct kiocb *iocb);
extern int aio_put_req(struct kiocb *iocb);
extern void kick_iocb(struct kiocb *iocb);
extern int aio_complete(struct kiocb *iocb, long res, long res2);
struct mm_struct;
extern void exit_aio(struct mm_struct *mm);
+#else
+static inline ssize_t wait_on_sync_kiocb(struct kiocb *iocb) { return 0; }
+static inline int aio_put_req(struct kiocb *iocb) { return 0; }
+static inline void kick_iocb(struct kiocb *iocb) { }
+static inline int aio_complete(struct kiocb *iocb, long res, long res2) { return 0; }
+struct mm_struct;
+static inline void exit_aio(struct mm_struct *mm) { }
+#endif /* CONFIG_AIO */
#define io_wait_to_kiocb(wait) container_of(wait, struct kiocb, ki_wait)
Index: linuxdev/init/Kconfig
===================================================================
--- linuxdev.orig/init/Kconfig
+++ linuxdev/init/Kconfig
@@ -724,6 +724,14 @@
option replaces shmem and tmpfs with the much simpler ramfs code,
which may be appropriate on small systems without swap.
+config AIO
+ bool "Enable AIO support" if EMBEDDED
+ default y
+ help
+ This option enables POSIX asynchronous I/O which may by used
+ by some high performance threaded applications. Disabling
+ this option saves about 7k.
+
config VM_EVENT_COUNTERS
default y
bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
Index: linuxdev/kernel/sys_ni.c
===================================================================
--- linuxdev.orig/kernel/sys_ni.c
+++ linuxdev/kernel/sys_ni.c
@@ -125,6 +125,11 @@
cond_syscall(sys_vm86);
cond_syscall(compat_sys_ipc);
cond_syscall(compat_sys_sysctl);
+cond_syscall(sys_io_setup);
+cond_syscall(sys_io_destroy);
+cond_syscall(sys_io_submit);
+cond_syscall(sys_io_cancel);
+cond_syscall(sys_io_getevents);
/* arch-specific weak syscall entries */
cond_syscall(sys_pciconfig_read);
Index: linuxdev/kernel/sysctl.c
===================================================================
--- linuxdev.orig/kernel/sysctl.c
+++ linuxdev/kernel/sysctl.c
@@ -1290,6 +1290,7 @@
.extra1 = &zero,
.extra2 = &two,
},
+#ifdef CONFIG_AIO
{
.procname = "aio-nr",
.data = &aio_nr,
@@ -1304,6 +1305,7 @@
.mode = 0644,
.proc_handler = &proc_doulongvec_minmax,
},
+#endif /* CONFIG_AIO */
#ifdef CONFIG_INOTIFY_USER
{
.ctl_name = FS_INOTIFY,
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Richard Danter @ 2008-07-29 11:39 UTC (permalink / raw)
To: Bart Van Assche; +Cc: Marco Stornelli, Embedded Linux mailing list
In-Reply-To: <e2e108260807290150tabb95d8vd080c069aab5d24@mail.gmail.com>
2008/7/29 Bart Van Assche <bart.vanassche@gmail.com>:
> On Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli
> <marco.stornelli@coritel.it> 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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bernd Petrovitsch @ 2008-07-29 9:47 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: linux-embedded
In-Reply-To: <200807291058.06240.neundorf@eit.uni-kl.de>
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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Alexander Neundorf @ 2008-07-29 8:58 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <1217319612.24988.15.camel@spike.firmix.at>
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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bart Van Assche @ 2008-07-29 8:50 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Embedded Linux mailing list
In-Reply-To: <488EC964.2030400@coritel.it>
On Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli
<marco.stornelli@coritel.it> 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.
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Marco Stornelli @ 2008-07-29 8:35 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Robert P. J. Day, Embedded Linux mailing list, Alexander Neundorf
In-Reply-To: <1217319612.24988.15.camel@spike.firmix.at>
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
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Bernd Petrovitsch @ 2008-07-29 8:20 UTC (permalink / raw)
To: Robert P. J. Day
Cc: Marco Stornelli, Embedded Linux mailing list, Alexander Neundorf
In-Reply-To: <200807290951.34563.neundorf@eit.uni-kl.de>
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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Alexander Neundorf @ 2008-07-29 7:51 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Embedded Linux mailing list
In-Reply-To: <488EC964.2030400@coritel.it>
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 majordomo@vger.kernel.org
> > 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
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Marco Stornelli @ 2008-07-29 7:40 UTC (permalink / raw)
To: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
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 majordomo@vger.kernel.org
> 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
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Roberto A. Foglietta @ 2008-07-29 5:42 UTC (permalink / raw)
To: Ben Nizette; +Cc: Robert P. J. Day, Embedded Linux mailing list
In-Reply-To: <1217281654.3546.16.camel@moss.renham>
2008/7/28 Ben Nizette <bn@niasdigital.com>:
>
> On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
>> just curious -- how many folks are working in C++ in their embedded
>> linux work?
>
[cut]
> Of course a largish number don't really need to write any code at all.
> They just need to wire up existing programs to do what they want then
> maybe glue a bit of PHP between that and the user so it doesn't /look/
> like Linux from the outside.
>
Apart kernel space and its modules I use C and shell script for
gluing all togheter!
In the last project I used 4423 lines of shell script as glue for C
applications.
:-)
Cheers,
--
/roberto
http://www.roberto.foglietta.name/work
^ permalink raw reply
* Re: [ANNOUNCE] udev 125 release
From: Marco d'Itri @ 2008-07-29 2:10 UTC (permalink / raw)
To: David VomLehn; +Cc: linux-hotplug, Linux Embedded Maillist
In-Reply-To: <488E7827.7010106@cisco.com>
On Jul 29, David VomLehn <dvomlehn@cisco.com> wrote:
>> Also, they can be edited manually while /var data cannot.
> I don't know of any problems with editing /var data manually, but your
It's one of the basic rules which have always defined /var. From FHS 2.3:
/var/lib : Variable state information
Purpose
This hierarchy holds state information pertaining to an application or the
system. State information is data that programs modify while they run, and that
pertains to one specific host. Users must never need to modify files in /var/
lib to configure a package's operation.
> Note that embedded systems are not the only case where read-only root
> filesystems may arise. They are also used when your root filesystem is on
> a CDROM or DVD, or when you have a read-only root filesystem so you can
> network-mount it on multiple nodes. These cases influenced the Filesystem
> Hierarchy Standard people to make /etc read-only. So, I think that using
> /etc for "on-the-fly" generated udev rules is an issue in a number of
> situations.
Live CDs do not really need persistent status and in my experience
both these and embedded systems tend to use lots of special-purpose
hacks anyway.
The generated rules *are* a configuration file and there are endless
generated configuration files in /etc (tipically they are generated
once at install time, but on most systems the same applies to udev too).
If you have a R/O /etc an no human administrator which can edit system
files then just copy the rules files from /dev/.udev/rules.d/ to /var
and restore them at the next boot before udevtrigger is run.
> need for this feature, but is it possible that you wouldn't need to
> generate rules *on-the-fly* until after mounting /var? If that were the
> case, you could still put the generated rules there.
It does not matter when they are generated but when they are used,
e.g. they may be needed to NFS-mount /var.
At least on Debian systems, networking is started before even local
file systems are mounted.
--
ciao,
Marco
^ permalink raw reply
* Re: [ANNOUNCE] udev 125 release
From: David VomLehn @ 2008-07-29 1:53 UTC (permalink / raw)
To: Marco d'Itri; +Cc: linux-hotplug, Linux Embedded Maillist
In-Reply-To: <20080728233224.GA27073@bongo.bofh.it>
Marco d'Itri wrote:
> On Jul 29, David VomLehn <dvomlehn@cisco.com> wrote:
>
>> If I understand what is meant by "on-the-fly generated rules", these are
>> not static and so don't belong under /etc. I think an FHS-conforming
>> place for these would be under /var somewhere, such as /var/lib/udev.
> /var may not be available yet when the files are needed, arguing to move
> them there is pointless.
> Also, they can be edited manually while /var data cannot.
I don't know of any problems with editing /var data manually, but your point
about /var not being available early enough to run udev is certainly an important
point to consider.
Note that embedded systems are not the only case where read-only root filesystems
may arise. They are also used when your root filesystem is on a CDROM or DVD, or
when you have a read-only root filesystem so you can network-mount it on multiple
nodes. These cases influenced the Filesystem Hierarchy Standard people to make
/etc read-only. So, I think that using /etc for "on-the-fly" generated udev
rules is an issue in a number of situations.
This looks like it might be a chicken-and-egg issue, where you may need to run
udev in order to be able to mount a writable filesystem in which to store rules
used by udev. I'm no expert on udev and what drove the need for this feature, but
is it possible that you wouldn't need to generate rules *on-the-fly* until after
mounting /var? If that were the case, you could still put the generated rules there.
Another possibility is simply to add a /var/lib/udev directory to the directories
in which rules may reside. If you have a read-only root filesystem, you'll just
have to mount /var before you can generate your own rules.
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Ben Nizette @ 2008-07-28 21:47 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
I hang out on AVRFreaks - an AVR and AVR32 support forum - quite a bit.
I personally think C++ is the language of the devil but I'd say that
around 50% of the people I talk to on 'freaks think otherwise. It's
certainly the language of choice.
There's also a surprising number (~5%?) using Java on a small JVM (eg
JamVM) and about the same using Python.
Of course a largish number don't really need to write any code at all.
They just need to wire up existing programs to do what they want then
maybe glue a bit of PHP between that and the user so it doesn't /look/
like Linux from the outside.
--Ben.
>
> rday
> --
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox