Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Linux Kernel Device Driver With C and C++

Reply
Thread Tools

Linux Kernel Device Driver With C and C++

 
 
SG
Guest
Posts: n/a
 
      11-03-2012
Am 03.11.2012 14:33, schrieb James Kuyper:
> [...]
> The built-in C types fall into a number of categories, based upon which
> operators work on them: arithmetic types, pointer types, array types,
> functions. Operator overloads work best when they make something that is
> of class type work like a member of one of those categories: extended
> numeric types such as quaternions or arrays, smart pointers, containers,
> or function objects. They only lead to confusion when used for other
> purposes. I don't imagine there's much need for extended arithmetic
> types in kernal programming. However, it seems to me that various kinds
> of smart pointers or containers could be useful, unless they can't be
> properly implemented. If there's any place where kernel code passes
> around function pointers, passing around function objects might be a
> reasonable alternative.


I agree. Last time I checked, the Linux kernel included things like
(intrusive) reference counting for some kinds of objects. Of course,
explicitly invoking functions for incrementing and decrementing these
counters is error-prone. This could be done with a smart pointer class
in C++. In all fairness I have to mention that I noticed an
optimization used in the kernel code. Whenever a function passes a
pointer to a ref-counted object to another function in the sense that
"ownership is transferred", there is no need to increment the
ref-counter for the new copy of the pointer and decrement it when the
original pointer is destroyed. In C++11 you could get the same
behaviour with a "move-enabled" smart pointer class (a class that
provides a move constructor and a move assignment operator).

With respect to overhead of C++, I'd like to point out a nice report on
the subject:
http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

Cheers!
SG

 
Reply With Quote
 
 
 
 
Nobody
Guest
Posts: n/a
 
      11-04-2012
On Sat, 03 Nov 2012 13:22:35 -0700, Keith Thompson wrote:

>>> int save_val(int i)
>>> {
>>> static int saved;


> I just compiled the above function with both gcc and g++ (version
> 4.7.0). The generated code was identical apart from a few different
> identifiers.
>
> Is there some g++ option that tells it to create a mutex?


A mutex is only required if the object has a constructor which cannot be
determined as being thread-safe. Primitive types don't require a mutex,
and types with a "simple" inline constructor may not require one (but it's
anyone's guess as to how much effort the compiler will go to before it
just adds a mutex to be on the safe side).

C doesn't have constructors, so static variables can be "initialised"
simply by mapping the segment which contains them (data, rodata, bss).

In C++, if a static variable has a constructor, then initialisation
requires code to be executed, and it may matter *when* that code is
executed.

Variables declared at file scope have their constructors executed in some
undefined order before main() is called. Local static variables have their
constructors executed the first time that the function is called ... or at
least the generated code must behave "as if" that is the case.

In some cases, it may not matter if the constructor is executed before
main(), or even at compile time (i.e. the variable may be stored within
the data segment in a fully-initialised state, requiring no code to be
executed at run time).

If it does matter when the constructor is executed, then it must be the
first time that the function is called. For multi-threaded code, this
requires a mutex to deal with the case where the "first time" occurs in
multiple threads simultaneously.

 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      11-04-2012
Am 04.11.2012 04:22, schrieb Nobody:
>
> A mutex is only required if the object has a constructor which cannot be
> determined as being thread-safe.


Not true. Dynamic initialization is not restricted to constructors.
You can also call arbitrary functions in a dynamic initializer.

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-04-2012
On 11/03/2012 06:01 PM, SG wrote:
> Am 03.11.2012 21:22, schrieb Keith Thompson:
>> Andrew Cooper <(E-Mail Removed)> writes:
>>> On 03/11/2012 13:33, James Kuyper wrote:

>> [...]
>>>> int save_val(int i)
>>>> {
>>>> static int saved;
>>>> int retval = saved;
>>>> saved = i;
>>>> return retval;
>>>> }
>>>
>>> There is a difference between how GCC and G++ treat static local
>>> variables. G++ generates extra code to put a mutex around it to prevent
>>> concurrent initialisation, and this is what requires the runtime
>>> support. (Admittedly this is only G++. Other C++ compilers wont, but
>>> best of luck to you trying to compile even the kernel header files

>> [...]
>>
>> I just compiled the above function with both gcc and g++ (version
>> 4.7.0). The generated code was identical apart from a few different
>> identifiers.
>>
>> Is there some g++ option that tells it to create a mutex?

>
> It does not surprize me that the code is equal. There is no dynamic
> initialization of 'saved' going on.


Andrew Cooper claimed that "Local static variables and global ctors and
dtors require runtime support, ...". He didn't restrict that claim to
dynamically initialized variables. The same is true of his claim that
G++ generates extra code for such variables.
--
James Kuyper
 
Reply With Quote
 
SG
Guest
Posts: n/a
 
      11-04-2012
Am 04.11.2012 14:18, schrieb James Kuyper:
> On 11/03/2012 06:01 PM, SG wrote:
>> Am 03.11.2012 21:22, schrieb Keith Thompson:
>>> Andrew Cooper <(E-Mail Removed)> writes:
>>>> On 03/11/2012 13:33, James Kuyper wrote:
>>> [...]
>>>>> int save_val(int i)
>>>>> {
>>>>> static int saved;
>>>>> int retval = saved;
>>>>> saved = i;
>>>>> return retval;
>>>>> }
>>>>
>>>> There is a difference between how GCC and G++ treat static local
>>>> variables. G++ generates extra code to put a mutex around it to prevent
>>>> concurrent initialisation, and this is what requires the runtime
>>>> support. (Admittedly this is only G++. Other C++ compilers wont, but
>>>> best of luck to you trying to compile even the kernel header files
>>> [...]
>>>
>>> I just compiled the above function with both gcc and g++ (version
>>> 4.7.0). The generated code was identical apart from a few different
>>> identifiers.
>>>
>>> Is there some g++ option that tells it to create a mutex?

>>
>> It does not surprize me that the code is equal. There is no dynamic
>> initialization of 'saved' going on.

>
> Andrew Cooper claimed that "Local static variables and global ctors and
> dtors require runtime support, ...". He didn't restrict that claim to
> dynamically initialized variables. The same is true of his claim that
> G++ generates extra code for such variables.


Right. Well, what he should have said is that the mutex only applies to
dynamic initializers for these static function-locals. But such kind of
initialization is not even legal in C as far as I know. So, I don't see
any problem with compiling C headers with a C++ compiler in this regard.

If you want to trigger synchronization, you have to use a dynamic
initializer like this:

const int* create_lut();

const int* get_lut()
{
static const int* lut = create_lut(); // dynamic initialization
}

(It doesn't have to be a object of a class type with a constructor).

If I compile this with G++ for x86-64 I see calls to following functions:
__cxa_guard_acquire
__cxa_guard_release
__cxa_guard_abort
which presumably are part of the "C++ runtime". If I add the switch
"-fno-threadsafe-statics", this goes away, but of course, it's not
longer a C++11 compliant behaviour.

Cheers!
SG

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-04-2012
In article <%QYks.12393$(E-Mail Removed)>,
Lew Pitcher <(E-Mail Removed)> wrote:
>On Friday 02 November 2012 00:07, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed)
>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.


Indeed. I want to know where are the topicality police when you need them!

Come on, Kiki! Why aren't you posting your usual "You are off topic in CLC"
messages? I'd have expected a half dozen of them, from you alone, by now.

Seriously folks! Here we are discussing C++ (a total no-no), Linux (A super
no-no!), and device drivers (not in userspace, so not topical here). Kiki,
what has happened to you?

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-05-2012
In article <(E-Mail Removed)>,
David Brown <(E-Mail Removed)> wrote:
>On 03/11/2012 00:48, Melzzzzz wrote:
>> On Sat, 03 Nov 2012 12:13:24 +1300
>> Ian Collins <(E-Mail Removed)> 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++

>
>To be accurate - Linus is hostile towards C++ for the kernel. He
>doesn't give a *beep* as to what other people use in user space, just as
>long as no one forces /him/ to use it.


Of course, that statement is equivalent to "I have no problem with <*>; I
just don't want them living in my neighborhood."

<*> Insert name of ethnic minority here.

--
The motto of the GOP "base": You can't be a billionaire, but at least you
can vote like one.
 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      11-05-2012
In article <(E-Mail Removed)>,
David Brown <(E-Mail Removed)> wrote:
>On 03/11/2012 00:48, Melzzzzz wrote:
>
>To be accurate - Linus is hostile towards C++ for the kernel.


Where to draw the line? Perhaps integrate a python interpreter
into the kernel so people can write drivers in python? How
about javascript? I could think of reasons for adding any of
these, but each one comes at a cost in support, runtime libraries,
and kernel bloat.

True story: I worked in a shop once where there was bourne-shell
code in the kernel. It was a kernel daemon. I forget what it was
used for, but we removed it on the next release.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-05-2012
On 11/06/12 09:30, Edward A. Falk wrote:
> In article<(E-Mail Removed)> ,
> David Brown<(E-Mail Removed)> wrote:
>> On 03/11/2012 00:48, Melzzzzz wrote:
>>
>> To be accurate - Linus is hostile towards C++ for the kernel.

>
> Where to draw the line? Perhaps integrate a python interpreter
> into the kernel so people can write drivers in python? How
> about javascript? I could think of reasons for adding any of
> these, but each one comes at a cost in support, runtime libraries,
> and kernel bloat.


Simple, the line is a language that causes none of the above. That
leave two choices, C or C++.

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-05-2012
On 11/05/2012 03:30 PM, Edward A. Falk wrote:
> In article <(E-Mail Removed)>,
> David Brown <(E-Mail Removed)> wrote:
>> On 03/11/2012 00:48, Melzzzzz wrote:
>>
>> To be accurate - Linus is hostile towards C++ for the kernel.

>
> Where to draw the line? Perhaps integrate a python interpreter
> into the kernel so people can write drivers in python? How
> about javascript? I could think of reasons for adding any of
> these, but each one comes at a cost in support, runtime libraries,
> and kernel bloat.


I think a reasonable place to draw the line is at object file
compatibility - if a compiler can generate an object file compatible
with kernel programming requirements, and with the rest of the files
that make up the kernel, it shouldn't matter which language it compiled
to generate that file (though it certainly helps if it's a language that
allows taking advantage of the information contained in the kernel's C
header files). C++ compilers can generate files compatible with those
produced by C compilers, and (with some exceptions) can read and
correctly interpret C header files, which is why the anti-C++ prejudice
described (and occasionally expressed) in this thread has surprised me.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel#autoload ignores custom monkey patched Kernel#require Lars Gierth Ruby 6 03-20-2010 10:35 PM
Why "Kernel.puts" and not "Kernel.put"? shadytrees@gmail.com Ruby 3 04-08-2006 01:42 PM
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x8fc Thread 0x934 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 1 03-24-2006 04:20 PM
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x8fc Thread 0x934 DBC 0x437b94 Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr bazzer ASP .Net 0 03-24-2006 02:22 PM
kernel hangs after "UNCOMPRESSING KERNEL OK BOOTING KERNEL" yogesh C Programming 3 02-12-2006 11:19 AM



Advertisments