Hi,
for one of our customers I have to port a Windows driver to
Linux. Large parts of the driver's backend code consists of
C++.
How can I compile this code with kbuild? The C++ support
(I have tested with 2.6.11) of kbuild seems to be incomplete /
not working.
cu, Marco
Please send me a CC as e-mail.
On Tue, 2005-09-06 at 13:23 +0200, Budde, Marco wrote:
[....]
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
Yes, because the official Linux kernel is pure C (using some gcc
extensions).
There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is
a) not integrated (and will probably never) and
b) you can't use parts of C++ anyway with it.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Tue, 6 Sep 2005, Budde, Marco wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
>
> cu, Marco
>
> Please send me a CC as e-mail.
>
The kernel is written in C and assembly. You need to port
the "kernel part" of your driver to C. Often windows "drivers"
are much more than "drivers" as known in Linux and Unix. They
often are the interface to another API such as LabVIEW,
Lab/Windows, CVI, etc., really an interface library. In
that case, the user-mode portion can be ported, often with
few changes, using C++.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, Sep 06, 2005 at 01:30:34PM +0200, Bernd Petrovitsch wrote:
> Yes, because the official Linux kernel is pure C (using some gcc
> extensions).
> There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is
> a) not integrated (and will probably never) and
> b) you can't use parts of C++ anyway with it.
All the language features are supported, according to them. The standard
library is not available that I can see, but it's not available in C
either, in the kernel.
- Chris
On 9/6/05, Budde, Marco <[email protected]> wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
>
That would be because the kernel is written in *C* (and some asm), *not* C++.
There /is/ no C++ support.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Tue, Sep 06, 2005 at 01:23:56PM +0200, Budde, Marco wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
If you really need C++ then creating your own ruleset in the Kbuild file
should do the trick.
Something like:
$(obj)/file.o: $(src)/file.cc
And you must provide rules for .cc -> .o
The link part may prove a bit difficult since you may have to link .c
and C++ code. Again writing your own linker ruler is probarly the way
forward.
I can give at a short look if you send something like a minimum set of
sample files (mixed .c and .C++ where you have tried doing some of the
obvious stuff yourself).
This is not about adding C++ to mainstrem kernel if someone thinks so,
this is just about helping Marco.
Sam
On Tue, 6 Sep 2005, Jesper Juhl wrote:
> On 9/6/05, Budde, Marco <[email protected]> wrote:
> > Hi,
> >
> > for one of our customers I have to port a Windows driver to
> > Linux. Large parts of the driver's backend code consists of
> > C++.
> >
> > How can I compile this code with kbuild? The C++ support
> > (I have tested with 2.6.11) of kbuild seems to be incomplete /
> > not working.
> >
>
> That would be because the kernel is written in *C* (and some asm), *not* C++.
> There /is/ no C++ support.
Which is too bad. You can do stuff much more elegant, effectively and
safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
it up to the user to make sure the type-casts are done OK every time. You
can with macros do some dynamic typing, but not nearly as effectively as
with templates, and those macros always comes very, very ugly. (Some say
templates are ugly, but they first become ugly when they are used
way beyond what you can do with macros.)
I think it can only be a plus to Linux to add C++ support for at least
out-of-mainline drivers. Adding drivers written in C++ into the mainline
is another thing.
Esben
On Wed, 7 Sep 2005, Esben Nielsen wrote:
> On Tue, 6 Sep 2005, Jesper Juhl wrote:
>
> > On 9/6/05, Budde, Marco <[email protected]> wrote:
> > > Hi,
> > >
> > > for one of our customers I have to port a Windows driver to
> > > Linux. Large parts of the driver's backend code consists of
> > > C++.
> > >
> > > How can I compile this code with kbuild? The C++ support
> > > (I have tested with 2.6.11) of kbuild seems to be incomplete /
> > > not working.
> > >
> >
> > That would be because the kernel is written in *C* (and some asm), *not* C++.
> > There /is/ no C++ support.
>
> Which is too bad. You can do stuff much more elegant, effectively and
> safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> it up to the user to make sure the type-casts are done OK every time. You
> can with macros do some dynamic typing, but not nearly as effectively as
> with templates, and those macros always comes very, very ugly. (Some say
> templates are ugly, but they first become ugly when they are used
> way beyond what you can do with macros.)
>
> I think it can only be a plus to Linux to add C++ support for at least
> out-of-mainline drivers. Adding drivers written in C++ into the mainline
> is another thing.
Please announce it and the URL when you have done it.
--
~Randy
On 9/7/05, Esben Nielsen <[email protected]> wrote:
> On Tue, 6 Sep 2005, Jesper Juhl wrote:
>
> > On 9/6/05, Budde, Marco <[email protected]> wrote:
> > > Hi,
> > >
> > > for one of our customers I have to port a Windows driver to
> > > Linux. Large parts of the driver's backend code consists of
> > > C++.
> > >
> > > How can I compile this code with kbuild? The C++ support
> > > (I have tested with 2.6.11) of kbuild seems to be incomplete /
> > > not working.
> > >
> >
> > That would be because the kernel is written in *C* (and some asm), *not* C++.
> > There /is/ no C++ support.
>
> Which is too bad. You can do stuff much more elegant, effectively and
> safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> it up to the user to make sure the type-casts are done OK every time. You
> can with macros do some dynamic typing, but not nearly as effectively as
> with templates, and those macros always comes very, very ugly. (Some say
> templates are ugly, but they first become ugly when they are used
> way beyond what you can do with macros.)
>
> I think it can only be a plus to Linux to add C++ support for at least
> out-of-mainline drivers. Adding drivers written in C++ into the mainline
> is another thing.
>
I was not trying to start a discussion about the merrits of C vs C++.
I was simply responding to marco's comment that "C++ support ... of
kbuild seems to be incomplete / not working".
As for C++ vs C. I don't have anything against C++. I use it a lot
for userspace programs. I'm not sure I agree that it would be
appropriate for the kernel though, but that's a whole other
discussion.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Wed, 07 Sep 2005 00:20:11 +0200, Esben Nielsen said:
> Which is too bad. You can do stuff much more elegant, effectively and
> safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> it up to the user to make sure the type-casts are done OK every time. You
> can with macros do some dynamic typing, but not nearly as effectively as
> with templates, and those macros always comes very, very ugly. (Some say
> templates are ugly, but they first become ugly when they are used
> way beyond what you can do with macros.)
>
> I think it can only be a plus to Linux to add C++ support for at least
> out-of-mainline drivers. Adding drivers written in C++ into the mainline
> is another thing.
http://www.tux.org/lkml/#s15-3 Why don't we rewrite the Linux kernel in C++?
On Tue, 2005-09-06 at 17:08 -0400, Chris Frey wrote:
> On Tue, Sep 06, 2005 at 01:30:34PM +0200, Bernd Petrovitsch wrote:
> > Yes, because the official Linux kernel is pure C (using some gcc
> > extensions).
> > There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is
> > a) not integrated (and will probably never) and
> > b) you can't use parts of C++ anyway with it.
>
> All the language features are supported, according to them. The standard
> library is not available that I can see, but it's not available in C
> either, in the kernel.
ACK (and the few necessary equal or similar functions of the standard C
lib are implemented directly).
It depends on the to-be-integrated C++ source if it is clean enough from
these features (let alone from Win* specific stuff) so that it makes
sense to really integrate it (so that future versions can replace it
more easily) and just convert it to pure C (which may be less work now
but more of a maintenance headache).
And no, I don't think that building a "windriverwrapper" (a la
ndiswrapper) is a useful thing.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Hi,
>> That would be because the kernel is written in *C* (and some asm),
*not* C++.
I cannot see the connection. At the end everything gets converted
to assembler/opcode. In the user space I can mix C and C++ code
without any problems, why should this not be possible in the
kernel mode?
>> There /is/ no C++ support.
This will be a problem in future. Nearly nobody will start a new
larger project (driver, user space software, embedded firmware)
using non OO languages today. So porting eg. Windows drivers to
Linux is nearly impossible without C++ support.
E.g. in my case the Windows source code has got more than 10 MB.
Nobody will convert such an amount of code from C++ to C.
This would take years.
> I think it can only be a plus to Linux to add C++ support for at least
> out-of-mainline drivers. Adding drivers written in C++ into the
mainline
> is another thing.
Right.
cu, Marco
On Tue, 6 Sep 2005 [email protected] wrote:
> On Wed, 07 Sep 2005 00:20:11 +0200, Esben Nielsen said:
>
> > Which is too bad. You can do stuff much more elegant, effectively and
> > safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> > it up to the user to make sure the type-casts are done OK every time. You
> > can with macros do some dynamic typing, but not nearly as effectively as
> > with templates, and those macros always comes very, very ugly. (Some say
> > templates are ugly, but they first become ugly when they are used
> > way beyond what you can do with macros.)
> >
> > I think it can only be a plus to Linux to add C++ support for at least
> > out-of-mainline drivers. Adding drivers written in C++ into the mainline
> > is another thing.
>
> http://www.tux.org/lkml/#s15-3 Why don't we rewrite the Linux kernel in C++?
>
I can't see it should be _that_ hard to make the kernel C++ friendly. At work
I use a RTOS written in plain C but where you can easily use C++ in kernel
space (there is no user-space :-). We use gcc by the way.
It has been done for Linux as well
(http://netlab.ru.is/pronto/pronto_code.shtml). Why can't this kind of
stuff be merged into the kernel? Why is there no efford to do so??
It is one of those projects I would have liked to spend time on if I had
any, but not if it would be rejected in the mainline no matter how little
intrusive it is.
What I ague for is that people find out _what_ can be accepted in the
mainline with regard to C++. If the maintainers could somehow signal
that a CONFIG_CPP_SUPPORT would be a acceptable option in the mainline
tree I am sure someone (not me out of lag of time) would make a patch and
submit it. I am sure distributions like RedHat would skip kernels with
CONFIG_CPP_SUPPORT=y once it was there.
Esben
PS. Do the above people break GPL by forcing people to accept a
license-agreement before downloading a patch to the kernel? Shouldn't they
provide a direct url?
On Wed, 07 Sep 2005 11:13:24 +0200, "Budde, Marco" said:
> E.g. in my case the Windows source code has got more than 10 MB.
> Nobody will convert such an amount of code from C++ to C.
> This would take years.
Do you have any *serious* intent to drop 10 *megabytes* worth of driver
into the kernel??? (Hint - *everything* in drivers/net/wireless *totals*
to only 2.7M).
A Linux device driver isn't the same thing as a Windows device driver - much of
a Windows driver is considered "userspace" on Linux, and you're free to do that
in C++ if you want.
BTW you kill threading.
On Wed, 2005-09-07 at 11:13 +0200, Budde, Marco wrote:
[...]
> >> That would be because the kernel is written in *C* (and some asm),
> *not* C++.
>
> I cannot see the connection. At the end everything gets converted
> to assembler/opcode. In the user space I can mix C and C++ code
Yup. And exported symbols for the linker.
> without any problems, why should this not be possible in the
Yes, this is a general problem with integrated c/c++ stuff like
Win-Visual C++. People think that they can mix it freely, in fact they
are using *only* C++ (it just happens that some part of the source is
compilable with a C compiler, but since you compile everything with the
C++ compiler pressing F9, no one sees the difference).
Why do you think are all these "#ifdef _cpluplus" stuff in the header
files for?
> kernel mode?
Try linking also in the user space, not only compilation.
Second read in the standards about the difference between hosted and
standalone environments and think on the differences.
> >> There /is/ no C++ support.
>
> This will be a problem in future. Nearly nobody will start a new
No.
> larger project (driver, user space software, embedded firmware)
We re on linux-kernel@ here, so we don't care *here* for user-space
software (only for the interface - i.e. sys-calls).
And for embedded usage C++ is unsusable in user-space too since it will
ex-bloat the whole software if people simply pull-in usual and/or common
C++ libraries like the STL and use them without knowing how much object
code they explode with it (if used without thinking).
> using non OO languages today. So porting eg. Windows drivers to
Which is again wrong. You can OO software without OO languages (though
you loose some nice features and checking).
> Linux is nearly impossible without C++ support.
Is is impossible anyways since the in-kernel interfaces are probably
quite different (though I don't know anything about ).
> E.g. in my case the Windows source code has got more than 10 MB.
> Nobody will convert such an amount of code from C++ to C.
> This would take years.
First, how much of it is really the source of a kernel driver (in the
sense of a Unix/Linux kernel driver)?
And second, no one expects that you convert your driver source. Just
write it from scratch (since you know the internals of the hardware
quite well it should take only a few weeks).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Wed, 07 Sep 2005 11:21:42 +0200, Esben Nielsen said:
> I use a RTOS written in plain C but where you can easily use C++ in kernel
> space (there is no user-space :-). We use gcc by the way.
This isn't RTOS, in case you haven't noticed. ;)
> It has been done for Linux as well
> (http://netlab.ru.is/pronto/pronto_code.shtml). Why can't this kind of
> stuff be merged into the kernel? Why is there no efford to do so??
Quoting http://netlab.ru.is/exception/LinuxCXX.shtml:
"The code is installed by applying a patch to the Linux kernel and enables the
full use of C++ using the GNU g++ compiler. Programmers that have used C++ in
Linux kernel modules have primarily been using classes and virtual functions,
but not global constructors. dynamic type checking and exceptions. Using even
this small part of C++ requires each programmer to write some supporting
routines. Using the rest of C++ includes porting the C++ ABI that accompanies
GNU g++ to the Linux kernel, and to enable global constructors and destructors."
So let's see - no constructors, no type checking, no exceptions, and using
virtual functions requires the programmer to write the glue code that
programmers want to use C++ to *avoid* writing. Sounds like "We stripped out
all the reasons programmers want to use C++ just so we can say we use C++ in
the kernel".
So, other than wank value, what *actual* advantages are there to using this
limited subset of C++ in the kernel?
Hi,
> Do you have any *serious* intent to drop 10 *megabytes* worth of
driver
> into the kernel??? (Hint - *everything* in drivers/net/wireless
*totals*
> to only 2.7M).
no, I don't. No every module has to go into the standard kernel :-).
> A Linux device driver isn't the same thing as a Windows device driver
- much of
> a Windows driver is considered "userspace" on Linux, and you're free
to do that
> in C++ if you want.
Well, it is not the first driver I am writing for Linux.
So yes, I do know, what is part of a Linux driver and
what is not.
cu, Marco
On Wed, 7 Sep 2005 [email protected] wrote:
> On Wed, 07 Sep 2005 11:13:24 +0200, "Budde, Marco" said:
>
> > E.g. in my case the Windows source code has got more than 10 MB.
> > Nobody will convert such an amount of code from C++ to C.
> > This would take years.
>
> Do you have any *serious* intent to drop 10 *megabytes* worth of driver
> into the kernel??? (Hint - *everything* in drivers/net/wireless *totals*
> to only 2.7M).
>
For a special perpose embedded application, doing it all in kernel space
would be the first, effective hack.
> A Linux device driver isn't the same thing as a Windows device driver - much of
> a Windows driver is considered "userspace" on Linux, and you're free to do that
> in C++ if you want.
>
Yes, moving stuff to user-space would be the way to go - unless it kills
performance!
Esben
On Wed, 7 Sep 2005 [email protected] wrote:
> On Wed, 07 Sep 2005 11:21:42 +0200, Esben Nielsen said:
>
> > I use a RTOS written in plain C but where you can easily use C++ in kernel
> > space (there is no user-space :-). We use gcc by the way.
>
> This isn't RTOS, in case you haven't noticed. ;)
Well, with Ingo's preempt-RT patch it is becomming a RT-OS, but that is
not the issue here.
>
> > It has been done for Linux as well
> > (http://netlab.ru.is/pronto/pronto_code.shtml). Why can't this kind of
> > stuff be merged into the kernel? Why is there no efford to do so??
>
> Quoting http://netlab.ru.is/exception/LinuxCXX.shtml:
>
> "The code is installed by applying a patch to the Linux kernel and enables the
> full use of C++ using the GNU g++ compiler. Programmers that have used C++ in
^^^^
> Linux kernel modules have primarily been using classes and virtual functions,
> but not global constructors. dynamic type checking and exceptions. Using even
> this small part of C++ requires each programmer to write some supporting
> routines. Using the rest of C++ includes porting the C++ ABI that accompanies
> GNU g++ to the Linux kernel, and to enable global constructors and destructors."
>
> So let's see - no constructors, no type checking, no exceptions, and using
> virtual functions requires the programmer to write the glue code that
> programmers want to use C++ to *avoid* writing. Sounds like "We stripped out
> all the reasons programmers want to use C++ just so we can say we use C++ in
> the kernel".
>
> So, other than wank value, what *actual* advantages are there to using this
> limited subset of C++ in the kernel?
>
If you cared to read the whole page you will notice that they talk about
the _past_. They have as I understand the page, they claim to have _fixed_
the problems.
Esben
On Wed, 2005-09-07 at 11:21 +0200, Esben Nielsen wrote:
> On Tue, 6 Sep 2005 [email protected] wrote:
>
> > On Wed, 07 Sep 2005 00:20:11 +0200, Esben Nielsen said:
> >
> > > Which is too bad. You can do stuff much more elegant, effectively and
> > > safer in C++ than in C. Yes, you can do inheritance in C, but it leaves
> > > it up to the user to make sure the type-casts are done OK every time. You
> > > can with macros do some dynamic typing, but not nearly as effectively as
> > > with templates, and those macros always comes very, very ugly. (Some say
> > > templates are ugly, but they first become ugly when they are used
> > > way beyond what you can do with macros.)
> > >
> > > I think it can only be a plus to Linux to add C++ support for at least
> > > out-of-mainline drivers. Adding drivers written in C++ into the mainline
> > > is another thing.
> >
> > http://www.tux.org/lkml/#s15-3 Why don't we rewrite the Linux kernel in C++?
>
> I can't see it should be _that_ hard to make the kernel C++ friendly. At work
> I use a RTOS written in plain C but where you can easily use C++ in kernel
> space (there is no user-space :-). We use gcc by the way.
Of course. Probably the easiest way is
-) to provide a pure C interface (read: write functions with C linkage
that call your C++ stuff) to your C++ stuff
-) compile your C++ sources separately
-) kill all not-existing features needed by the linker and other
programs (or implement them in the kernel/your module).
> PS. Do the above people break GPL by forcing people to accept a
> license-agreement before downloading a patch to the kernel? Shouldn't they
> provide a direct url?
As long as the license agreement does not conflict with the GPL, I can't
see a legal problem. And you can download their source - which is
probably GPL - and put it online wherever you want.
It is inpolite though, IMHO. But it is also inpolite to top-post, break
threads, include meaningless disclaimers, etc.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Budde, Marco <[email protected]> wrote:
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
Maybe this can help: http://en.wikipedia.org/wiki/Cfront
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Hi,
> Yes, this is a general problem with integrated c/c++ stuff like
> Win-Visual C++.
not all Windows users do not know what they are doing :-).
Speaking for myself: I am programming under Linux and
Windows (with more than 10 years experience in C and C++)
and I do know the differences. So please do not call
people idiots only because the are writing software under
Windows.
> People think that they can mix it freely,
They can do.
> in fact they
> are using *only* C++ (it just happens that some part of the source is
> compilable with a C compiler, but since you compile everything with
the
> C++ compiler pressing F9, no one sees the difference).
So if I compile a library with gcc and link the code to a g++
program, the complete program gets compiled with the C++ compiler?
Interesting :-).
> Why do you think are all these "#ifdef _cpluplus" stuff in the header
> files for?
To support mixed code, because otherwise e.g. a C++ compiler cannot
use a library compiled with a C compiler.
> We re on linux-kernel@ here, so we don't care *here* for user-space
> software (only for the interface - i.e. sys-calls).
When you develop a complete product consisting of the embedded
firmware, the driver, and the user space software, you always have
to decide, where to put the code. And in such a case it is really
nice, when you can use the same language in all layers.
> And for embedded usage C++ is unsusable in user-space too since it
will
> ex-bloat the whole software if people simply pull-in usual and/or
common
> C++ libraries like the STL and use them without knowing how much
object
> code they explode with it (if used without thinking).
This applies for all languages. If you do not know, what you are doing,
you can write really awful code. And I cannot agree, that C++ results to
larger code.
> Which is again wrong. You can OO software without OO languages (though
> you loose some nice features and checking).
If you are an experienced OO programmer, you do not want to use
languages like plain C, because they result into worse code and
make life more difficult. If you do not like any kind of abstraction,
why are you using C instead of pure assembler?
> Is is impossible anyways since the in-kernel interfaces are probably
> quite different (though I don't know anything about ).
A lot of code (backend code) does not need any access to
libraries/interfaces.
> First, how much of it is really the source of a kernel driver (in the
> sense of a Unix/Linux kernel driver)?
At the moment you really need all the code to control all variants of
the hardware. Yes, it is not a good design. We know it, our customer
knows it, but at the moment we have to live with the situation.
> And second, no one expects that you convert your driver source. Just
> write it from scratch
Can you estimate what such a redesign would cost our customers?
You would need several years to redesign the concept.
cu, Marco
On Wed, 2005-09-07 at 14:04 +0200, Budde, Marco wrote:
[...]
> > Yes, this is a general problem with integrated c/c++ stuff like
> > Win-Visual C++.
>
> not all Windows users do not know what they are doing :-).
> Speaking for myself: I am programming under Linux and
> Windows (with more than 10 years experience in C and C++)
> and I do know the differences. So please do not call
> people idiots only because the are writing software under
> Windows.
I didn't call anyone an idiot, at most I could have meant just
in-experieced in "C vs C++" things. I just happen to know a lot of
people where above is (sadly enough) correct.
> > People think that they can mix it freely,
>
> They can do.
If they know, what they do, yes.
> > in fact they
> > are using *only* C++ (it just happens that some part of the source is
> > compilable with a C compiler, but since you compile everything with
> the
> > C++ compiler pressing F9, no one sees the difference).
>
> So if I compile a library with gcc and link the code to a g++
> program, the complete program gets compiled with the C++ compiler?
> Interesting :-).
No (and I didn't wrote above either).
And BTW it is quite nice to see the differences between gcc and g++ on
little things like the signedness of enums etc. if you compile identical
C-source with both.
And you have to take care that the linkage is correct. For the largest
part this is already standard and works out of the box. But if the
C-library is self-written, things may be different.
> > We re on linux-kernel@ here, so we don't care *here* for user-space
> > software (only for the interface - i.e. sys-calls).
>
> When you develop a complete product consisting of the embedded
> firmware, the driver, and the user space software, you always have
> to decide, where to put the code. And in such a case it is really
> nice, when you can use the same language in all layers.
ACK.
> > And for embedded usage C++ is unsusable in user-space too since it
> will
> > ex-bloat the whole software if people simply pull-in usual and/or
> common
> > C++ libraries like the STL and use them without knowing how much
> object
> > code they explode with it (if used without thinking).
>
> This applies for all languages. If you do not know, what you are doing,
> you can write really awful code. And I cannot agree, that C++ results to
> larger code.
Not necessarily. But with (badly used) C++ templates (read: using e.g.
STL, I don't know much about the boost lib) things can get much worse
*much* faster then with preprocessor magic.
> > Which is again wrong. You can OO software without OO languages (though
> > you loose some nice features and checking).
>
> If you are an experienced OO programmer, you do not want to use
> languages like plain C, because they result into worse code and
> make life more difficult. If you do not like any kind of abstraction,
There are environments where you don't have choice. E.g. if your
embedded system must boot from 4MB.
> why are you using C instead of pure assembler?
Because C is only a portable assembler? ;-)
Because there are several quite usable libs around which also fit into
embedded systems?
And the abstraction (or better: the level of abstraction) is the point.
Of course it is easier to use e.g. perl where buffer-overflows are not
possible and strings and arrays are handled natively etc. But you have
probably other problems too and less control (und usually knowledge)
what is really going on in the background.
> Can you estimate what such a redesign would cost our customers?
> You would need several years to redesign the concept.
I leave it up to you and your customers to decide and won't interfere
with the decision.
So apparently you're stuck with the C++-patch from .is to the kernel and
get the driver to work with this.
*If* you do this, I would interested on the needed effort and problems
(like missing features etc.), just to get an rough idea what it really
took in at least one project.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Budde, Marco wrote:
> make life more difficult. If you do not like any kind of abstraction,
> why are you using C instead of pure assembler?
>
This has nothing to do with the linux kernel anymore, so can the
thread be killed from lkml please? (Not to be rude; understand
the s/n ratio is bad at the best of times).
Thanks,
Nick
Send instant messages to your online friends http://au.messenger.yahoo.com
On Wed, 2005-09-07 at 12:17 +0200, Budde, Marco wrote:
> Well, it is not the first driver I am writing for Linux.
> So yes, I do know, what is part of a Linux driver and
> what is not.
It should be fairly obvious. Windows drivers do all kinds of crap that
just obviously doesn't belong in the kernel, often to implement features
that Windows doesn't have. For example half the Windows sound drivers
do AC3 decoding inside the driver (and half of those lie and say it's a
hardware AC3 decoder).
On Linux we use a simple userspace program called ac3dec for that.
Anything that can reasonably be done in userspace belongs in userspace.
We DON'T do things in the kernel just because it would be slightly
faster or it has an RT constraint or the kernel lacks some feature that
your driver wants or whatever.
Lee
On Tue, Sep 06, 2005 at 01:23:56PM +0200, Budde, Marco wrote:
> Hi,
>
> for one of our customers I have to port a Windows driver to
> Linux. Large parts of the driver's backend code consists of
> C++.
>
> How can I compile this code with kbuild? The C++ support
> (I have tested with 2.6.11) of kbuild seems to be incomplete /
> not working.
Since you did not send any sample code shall I assume this was not a
serious request?
Sam
Hi Sam,
>> How can I compile this code with kbuild? The C++ support
>> (I have tested with 2.6.11) of kbuild seems to be incomplete /
>> not working.
> Since you did not send any sample code shall I assume this was not a
> serious request?
it is of course a serious request.
At the moment we are using some additional rules for kbuild.
They have worked for a previous project of our customer and I
hope they will work for this project, too.
-------------------------------------------------------------------
include $(SRC_ROOT)comps/Kbuild.includes
EXTRA_CPPFLAGS += -fno-exceptions -fno-rtti \
$(INCLUDE_DIRS)
EXTRA_CFLAGS += $(INCLUDE_DIRS)
%.o: %.cpp FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_cpp)
quiet_cmd_cc_o_cpp = C++ $(quiet_modtag) $@
ifndef CONFIG_MODVERSIONS
cmd_cc_o_cpp = $(CXX) $(cpp_flags) -c -o $@ $<
else
cmd_cc_o_cpp = $(CXX) $(cpp_flags) -c -o $(@D)/.tmp_$(@F) $<
endif
define rule_cc_o_cpp
$(if $($(quiet)cmd_checksrc),echo ' $($(quiet)cmd_checksrc)';)
\
$(cmd_checksrc)
\
$(if $($(quiet)cmd_cc_o_cpp),echo ' $($(quiet)cmd_cc_o_cpp)';)
\
$(cmd_cc_o_cpp);
\
$(cmd_modversions)
\
scripts/basic/fixdep $(depfile) $@ '$(cmd_cc_o_cpp)' >
$(@D)/.$(@F).tmp; \
rm -f $(depfile);
\
mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd
endef
-------------------------------------------------------------------
Hi Marco.
> At the moment we are using some additional rules for kbuild.
> They have worked for a previous project of our customer and I
> hope they will work for this project, too.
Following adds proper C++ support to kbuild.
Only composite objects are supported, but for your project thats
not an issue.
Sample Kbuild file:
obj-m := sam.o
EXTRA_CXXFLAGS := -DDEBUG
CXXFLAGS_file2.o := -DDEBUG2
sam-y := file1.o file2.o
I hope this is useful for your project, but do not count on having this
added to mainstream kernel.
sparse is not used - I do not assume you want to add C++ support to
sparse for now.
Also module versioning is excluded. Mainly because I did not bother test
it - it should be trivial to add.
Sam
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -322,6 +322,7 @@ AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
CC = $(CROSS_COMPILE)gcc
CPP = $(CC) -E
+CXX = $(CROSS_COMPILE)g++
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
STRIP = $(CROSS_COMPILE)strip
@@ -354,15 +355,18 @@ CFLAGS := -Wall -Wundef -Wstrict-proto
-fno-strict-aliasing -fno-common \
-ffreestanding
AFLAGS := -D__ASSEMBLY__
+CXXFLAGS := -Wall -Wundef -fno-strict-aliasing -fno-common \
+ -fno-exceptions -fno-rtti
export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION LOCALVERSION KERNELRELEASE \
- ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
+ ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC CXX\
CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE \
HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
export CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
export AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
+export CXXFLAGS
# When compiling out-of-tree modules, put MODVERDIR in the module
# tree rather than in the kernel tree. The kernel tree might
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -187,13 +187,36 @@ define rule_cc_o_c
mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd
endef
-# Built-in and composite module parts
-
%.o: %.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
+
+# C++ (.cpp) files
+# The C++ file is compiled and updated dependency information is generated.
+# (See cmd_cc_o_cxx + relevant part of rule_cc_o_cxx)
+
+# No support for module versioning for c++ (for now)
+quiet_cmd_cc_o_cxx = C++ $(quiet_modtag) $@
+ cmd_cc_o_cxx = $(CXX) $(cxx_flags) -c -o $@ $<
+
+define rule_cc_o_cxx
+ $(if $($(quiet)cmd_checksrc),echo ' $($(quiet)cmd_checksrc)';) \
+ $(if $($(quiet)cmd_cc_o_cxx),\
+ echo ' $(subst ','\'',$($(quiet)cmd_cc_o_cxx))';) \
+ $(cmd_cc_o_cxx); \
+ scripts/basic/fixdep $(depfile) $@ '$(subst ','\'',$(cmd_cc_o_cxx))' \
+ > $(@D)/.$(@F).tmp; \
+ rm -f $(depfile); \
+ mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd
+endef
+
+%.o: %.cpp FORCE
+ $(call if_changed_rule,cc_o_cxx)
+
+# Built-in and composite module parts
# Single-part modules are special since we need to mark them in $(MODVERDIR)
+# Also we do not support C++ single-file modules
$(single-used-m): %.o: %.c FORCE
$(call cmd,force_checksrc)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -87,7 +87,7 @@ modname_flags = $(if $(filter 1,$(words
_c_flags = $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F).o)
_a_flags = $(AFLAGS) $(EXTRA_AFLAGS) $(AFLAGS_$(*F).o)
_cpp_flags = $(CPPFLAGS) $(EXTRA_CPPFLAGS) $(CPPFLAGS_$(@F))
-
+_cxx_flags = $(CXXFLAGS) $(EXTRA_CXXFLAGS) $(CXXFLAGS_$(@F))
# If building the kernel in a separate objtree expand all occurrences
# of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/').
@@ -95,6 +95,7 @@ ifeq ($(KBUILD_SRC),)
__c_flags = $(_c_flags)
__a_flags = $(_a_flags)
__cpp_flags = $(_cpp_flags)
+__cxx_flags = $(_cxx_flags)
else
# Prefix -I with $(srctree) if it is not an absolute path
@@ -109,6 +110,7 @@ flags = $(foreach o,$($(1)),$(if $(filte
__c_flags = $(call addtree,-I$(obj)) $(call flags,_c_flags)
__a_flags = $(call flags,_a_flags)
__cpp_flags = $(call flags,_cpp_flags)
+__cxx_flags = $(call flags,_cpp_flags)
endif
c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
@@ -120,6 +122,10 @@ a_flags = -Wp,-MD,$(depfile) $(NO
cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(__cpp_flags)
+cxx_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
+ $(__cxx_flags) $(modkern_cflags) \
+ $(basename_flags) $(modname_flags)
+
ld_flags = $(LDFLAGS) $(EXTRA_LDFLAGS)
# Finds the multi-part object the current object will be linked into