![]() |
Linux Kernel Device Driver With C and C++
Hi all,
I hope this is the right place to ask this, but I want to write a device driver for Linux that offloads the main portion of the logic to a C++ file and `extern` the relevant pieces for inclusion in the main `C` file. I've successfully created a `hello world` executable but I don't know how to write the Makefile that will include the C++ library and compile it to a `.ko`. The simple tutorials don't seem to help. Any help is appreciated. -deech |
Re: Linux Kernel Device Driver With C and C++
deech wrote:
> I hope this is the right place to ask this, but I want to > write a device driver for Linux [...] I think you should try comp.os.linux.development.system cf. http://kasperd.net/~kasperd/comp.os....evelopment.faq Regards. |
Re: Linux Kernel Device Driver With C and C++
On 2012-11-02, deech <aditya.siram@gmail.com> wrote:
> Hi all, > I hope this is the right place to ask this, but I want to write a device > driver for Linux that offloads the main portion of the logic to a C++ file > and `extern` the relevant pieces for inclusion in the main `C` file. > > I've successfully created a `hello world` executable but I don't know how > to write the Makefile that will include the C++ library and compile it to > a `.ko`. The simple tutorials don't seem to help. Try this site: http://kernelnewbies.org/ Just a word of warning; Linux kernel development is done in C only and many there are pretty hostile to any suggestions that it should be done in C++. (I personally take no stance on the matter, whatever works for you is good enough.) Be prepared for some pretty harsh reactions. -- "C provides a programmer with more than enough rope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c |
Re: Linux Kernel Device Driver With C and C++
In article <slrnk977fj.v0o.angel+news@pearlgates.net>,
Angel <angel+news@spamcop.net> wrote: > >Try this site: >http://kernelnewbies.org/ > >Just a word of warning; Linux kernel development is done in C only and >many there are pretty hostile to any suggestions that it should be done >in C++. Good advice. Be aware that kernel programming is a radically different environment from user-level programming. Most significantly, there is no libc so many of the system services you take for granted in your usual programming environment are not available. This will go double for C++, and frankly, I'd be surprised if you could make it work unless you're very very careful. -- -Ed Falk, falk@despams.r.us.com http://thespamdiaries.blogspot.com/ |
Re: Linux Kernel Device Driver With C and C++
On 02/11/2012 10:18, Angel wrote:
> On 2012-11-02, deech <aditya.siram@gmail.com> wrote: >> Hi all, >> I hope this is the right place to ask this, but I want to write a device >> driver for Linux that offloads the main portion of the logic to a C++ file >> and `extern` the relevant pieces for inclusion in the main `C` file. >> >> I've successfully created a `hello world` executable but I don't know how >> to write the Makefile that will include the C++ library and compile it to >> a `.ko`. The simple tutorials don't seem to help. > > Try this site: > http://kernelnewbies.org/ > > Just a word of warning; Linux kernel development is done in C only and > many there are pretty hostile to any suggestions that it should be done > in C++. (I personally take no stance on the matter, whatever works for > you is good enough.) Be prepared for some pretty harsh reactions. > > As a Xen hypervisor and Linux kernel developer myself, I offer this rule of thumb. Only stuff which absolutely must be in the kernel should be in the kernel. Everything else should be in userspace. On a technical note, your chances of getting C++ working at all as a kernel module is virtually 0. You certainly wont be able to do exceptions or RTTI, and I cant offhand think of a way you would implement even the simple things like global constructors/destructors. On top of that, you will not have any libraries, and good luck using the kernel internal headers with C++ (given all of the C-only syntax they use). Dare I ask what your device driver is attempting to do? ~Andrew |
Re: Linux Kernel Device Driver With C and C++
On 11/02/2012 06:05 PM, Andrew Cooper wrote:
> On a technical note, your chances of getting C++ working at all as a > kernel module is virtually 0. You certainly wont be able to do > exceptions or RTTI, and I cant offhand think of a way you would > implement even the simple things like global constructors/destructors. > On top of that, you will not have any libraries, and good luck using the > kernel internal headers with C++ (given all of the C-only syntax they use). Ordinarily, I'd expect that if I used a C++ compiler essential as if it were C compiler - using only features that C++ shares with C, and using them only in ways that have the same meaning in C as in C++, and making appropriate use of extern "C" - that it shouldn't be a problem. However, your comment about "C-only syntax" would suggest otherwise. What specific types of syntax are you referring to? Are these C90 features that were dropped in C99, such as implicit int, or C99 features which have not yet been added to C++, such as restrict, or C features that were never supported in C++, but which few sane C programmers have voluntarily used for at least a decade, such as non-prototyped function declarations, or something else? When I think of how C++ differs from C, ctors and dtors are an important part of it, but I also think about member functions, inheritance, (single and multiple), function overloading, operator overloads, template classes. template functions, member access restrictions, virtual members, and virtual inheritance. Do any of these features cause problems for kernal programming? Most of these features can be emulated in C code; which is in fact how the earliest C++ compilers were implemented, which is why I'd be surprised if they were problematic. If they are, would the corresponding C code be equally problematic? |
Re: Linux Kernel Device Driver With C and C++
On 11/03/12 11:45, James Kuyper wrote:
> On 11/02/2012 06:05 PM, Andrew Cooper wrote: >> On a technical note, your chances of getting C++ working at all as a >> kernel module is virtually 0. You certainly wont be able to do >> exceptions or RTTI, and I cant offhand think of a way you would >> implement even the simple things like global constructors/destructors. >> On top of that, you will not have any libraries, and good luck using the >> kernel internal headers with C++ (given all of the C-only syntax they use). > > Ordinarily, I'd expect that if I used a C++ compiler essential as if it > were C compiler - using only features that C++ shares with C, and using > them only in ways that have the same meaning in C as in C++, and making > appropriate use of extern "C" - that it shouldn't be a problem. > However, your comment about "C-only syntax" would suggest otherwise. > What specific types of syntax are you referring to? Are these C90 > features that were dropped in C99, such as implicit int, or C99 features > which have not yet been added to C++, such as restrict, or C features > that were never supported in C++, but which few sane C programmers have > voluntarily used for at least a decade, such as non-prototyped function > declarations, or something else? > > When I think of how C++ differs from C, ctors and dtors are an important > part of it, but I also think about member functions, inheritance, > (single and multiple), function overloading, operator overloads, > template classes. template functions, member access restrictions, > virtual members, and virtual inheritance. Do any of these features cause > problems for kernal programming? Most of these features can be emulated > in C code; which is in fact how the earliest C++ compilers were > implemented, which is why I'd be surprised if they were problematic. If > they are, would the corresponding C code be equally problematic? I can't speak for Linux modules, but in the BSD/Solaris world your observations are correct. As long as the C++ code does not require runtime library support, it is fine to use in kernel land. If you do accidentally use a feature that does require runtime library support, your code won't load and you soon realise the error of your ways. Been there and done that! In BSD/Solaris drivers, there are per-driver and per-instance interfaces and variables that map well to static and non-static class members. -- Ian Collins |
Re: Linux Kernel Device Driver With C and C++
On Friday 02 November 2012 00:07, in comp.lang.c, aditya.siram@gmail.com
wrote: Sorry clc, but this thread has gone on long enough > Hi all, > I hope this is the right place to ask this, No. It isn't. > but I want to write a device > driver for Linux that offloads the main portion of the logic to a C++ file > and `extern` the relevant pieces for inclusion in the main `C` file. Not a good idea. You might want to read the Linux-kernel Mailinglist faq, especially question 15.3 (http://www.tux.org/lkml/#s15-3) > I've successfully created a `hello world` executable but I don't know how > to write the Makefile that will include the C++ library and compile it to > a `.ko`. The simple tutorials don't seem to help. There are no tutorials because it is discouraged (read "forbidden by the lead kernel developers). The basic point is that, for various reasons (good or bad), the Linux kernel developers do not want, and do not support, kernel development using C++ in any form. If, as you say in a later post, you intend to code your C++ in 'extern "C" ' format, there is no reason to avoid coding your kernel development directly in C /instead of/ C++. OTOH, if you intend to use /even one/ feature of C++ that is not supported directly in C, then you are out of luck. And, name-mangling counts as a feature. HTH -- Lew Pitcher "In Skills, We Trust" |
Re: Linux Kernel Device Driver With C and C++
On Sat, 03 Nov 2012 12:13:24 +1300
Ian Collins <ian-news@hotmail.com> wrote: > > I can't speak for Linux modules, but in the BSD/Solaris world your > observations are correct. Linus is hostile toward C++ , so they would not accept any driver written in C++ ;) For home use I think there is no problem to write driver in any language, even modify kernel to support rtti and exceptions ;) -- drwxr-xr-x 2 bmaxa bmaxa 4096 Oct 31 23:14 . |
Re: Linux Kernel Device Driver With C and C++
On 11/03/12 12:39, Lew Pitcher wrote:
> On Friday 02 November 2012 00:07, in comp.lang.c, aditya.siram@gmail.com > wrote: > > Sorry clc, but this thread has gone on long enough > > >> Hi all, >> I hope this is the right place to ask this, > > No. It isn't. > >> but I want to write a device >> driver for Linux that offloads the main portion of the logic to a C++ file >> and `extern` the relevant pieces for inclusion in the main `C` file. > > Not a good idea. You might want to read the Linux-kernel Mailinglist faq, > especially question 15.3 (http://www.tux.org/lkml/#s15-3) > >> I've successfully created a `hello world` executable but I don't know how >> to write the Makefile that will include the C++ library and compile it to >> a `.ko`. The simple tutorials don't seem to help. > > There are no tutorials because it is discouraged (read "forbidden by the > lead kernel developers). > > The basic point is that, for various reasons (good or bad), the Linux kernel > developers do not want, and do not support, kernel development using C++ in > any form. If, as you say in a later post, you intend to code your C++ > in 'extern "C" ' format, there is no reason to avoid coding your kernel > development directly in C /instead of/ C++. That does not make sense. In C++, extern "C" is merely a means to provide linkage compatibility with C. It does not influence what goes on inside a function or module. > OTOH, if you intend to use /even one/ feature of C++ that is not supported > directly in C, then you are out of luck. And, name-mangling counts as a > feature. Name mangling is a consequence of C++ features, not a feature. If all the public interfaces of a module are declared extern "C", what goes on inside is irrelevant. -- Ian Collins |
| All times are GMT. The time now is 03:56 PM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.