Hi all,
I am in the initial stages of writing some C++ wrapper classes for the
kernel. So far its been an interesting process, mainly due to the use of
some C++ keywords in the kernel header files. Mostly gratuitous at that as
most of the C++ keyword uses I've encountered so far are the use of the
keyword "new" as variable names in some inlined functions. Well I've fixed
up the header files (I've used so far) and have been able to successfully
overload the new and delete keywords thus allowing me to properly construct
and deconstruct C++ objects within a kernel module. Well I've encountered a
couple of issues I hope someone can help me here.
So far my overloading of "new" works if I compile the module without
exceptions (-fno-exceptions). This is fine for myself as I prefer checking
for a NULL on a memory allocation error over handling an exception, plus the
resulting code appears to be much more efficient without exceptions by a
large order of magnitude. However I would like my C++ kernel support to
include exception support if possible so those whom may want to use it,
besides which it may yet prove itself useful. However allowing exceptions
in (if used apparently, via so far my overloading of "new") appears to put
an undefined reference to throw and (I think) terminate into the resulting
object file. Does someone know how I can resolve this?
I would like to add the ability for the wrapper classes' users to use
static member functions as the module initiation and cleanup functions. For
example:
class my_module
{
public:
static int load();
static void unload();
};
And use my_module::load() as the init_module function and
my_module::unload() as the cleanup_module function. The provided macros
module_init and module_exit should do this for me however I've encountered a
limitation in how gcc's "alias" feature is used. Apparently for C++ one
must pass the mangled name of the function in question. Is there a gcc
macro or function of some kind to do something like this:
int init_module() __attribute__((alias(mangle_name("load__9my_module"))));
int cleanup_module()
__attribute__((alias(mangle_name("unload__9my_module"))));
I need a function or macro like mangle_name above.
Another issue that I currently have is that I haven't been able to
figure out a way to get the module to properly initiate global objects.
Like so:
my_module mod1;
If I put this in the source file as a global function and load the
module, I've found that this module's constructor doesn't get called. I
figured out why and gcc's documentation backed me up. However I can't seam
to find any way to tell gcc to initiate the object file's global objects
from within the init_module function. I know a workaround would be to have
a pointer instead and allocate the object in init_module however I think its
best to avoid pointers whenever possible to reduce the chance of errors.
Anyone know how I can get gcc to insert the global initiation code from
within init_module?
On a side note:
So far C++'s use of the kernel headers has found a couple of areas in
which possible bugs exists. In one header file the typedef ssize_t is used
despite its definition not appearing in the source file or any of the
included header files. I've also encountered negative numbers being
assigned to unsigned numbers without a cast. And I've found completely
unnecessary use of the C++ keyword "new" as variable names in some inlined
functions.
Would patches be welcomed for one or more of these issues?
Thanks.
T. A. wrote:
> Hi all,
>
> I am in the initial stages of writing some C++ wrapper classes for the
> kernel.
>
> So far my overloading of "new" works if I compile the module without
> exceptions (-fno-exceptions). This is fine for myself as I prefer checking
> for a NULL on a memory allocation error over handling an exception, plus the
> resulting code appears to be much more efficient without exceptions by a
> large order of magnitude. However I would like my C++ kernel support to
> include exception support if possible so those whom may want to use it,
This will turn out to be nearly impossible. Please note that
the exception mechanisms in C++ are basically a second function
return path and are therefore not desirable at all for the following reasons:
1. It's silly becouse we have already a return path and page fault based
exception mechanisms in kernel, which is far better suited for the purposes
of the kernel then the C++ semantics. (Remarkable the KDE people recognize
that C++ exceptions are not a good thing...)
2. It's changing the stack layout for the kernel functions, and there
are few of them which rely on a particular stack layout (namely the
scheduler and some *.S files - look out for the asmlinkage attribute...)
> besides which it may yet prove itself useful. However allowing exceptions
> in (if used apparently, via so far my overloading of "new") appears to put
> an undefined reference to throw and (I think) terminate into the resulting
> object file. Does someone know how I can resolve this?
Yes I know - PLEASE JUST FORGET ABOUT IT.
> I would like to add the ability for the wrapper classes' users to use
> static member functions as the module initiation and cleanup functions. For
> example:
>
> class my_module
> {
> public:
> static int load();
> static void unload();
> };
>
> And use my_module::load() as the init_module function and
> my_module::unload() as the cleanup_module function. The provided macros
> module_init and module_exit should do this for me however I've encountered a
> limitation in how gcc's "alias" feature is used. Apparently for C++ one
> must pass the mangled name of the function in question. Is there a gcc
> macro or function of some kind to do something like this:
>
> int init_module() __attribute__((alias(mangle_name("load__9my_module"))));
> int cleanup_module()
> __attribute__((alias(mangle_name("unload__9my_module"))));
I guess the above wouldn't work due to the games which the linkage scripts
play already on the init_module and cleanup_module function.
Maybe you would rather wan't to have a look at those scripts themself
and adjust them accordingly? (Possibly having a mangling tool at hand...)
> I need a function or macro like mangle_name above.
>
> Another issue that I currently have is that I haven't been able to
> figure out a way to get the module to properly initiate global objects.
> Like so:
>
> my_module mod1;
Well the "hidden C++" initializations you should propably forget
about - they are not desirable inside the kernel, becouse this
C++ mechanism is annihilating the expliciticity of the programm controll
flow of C.
> On a side note:
>
> So far C++'s use of the kernel headers has found a couple of areas in
> which possible bugs exists. In one header file the typedef ssize_t is used
> despite its definition not appearing in the source file or any of the
> included header files. I've also encountered negative numbers being
> assigned to unsigned numbers without a cast. And I've found completely
> unnecessary use of the C++ keyword "new" as variable names in some inlined
> functions.
>
> Would patches be welcomed for one or more of these issues?
Personally I would just like to have the ability to compile the
kernel with C++ just for the following two reaons:
1. C++ is a bit tighter on type checking, which would give better regreesions.
2. Modern GCC versions generate generally better code for C if compiled as C++
files, since the language gives tighter semantics to some constructs.
However I wouldn't for certainly like to see the kernel beeing transformed
in to C++. Expierence has shown over time that the chances for abuse of this
programming language are just too high. Language design idiocies like the
following come immediately in to mind:
1. Templates.
2. Runtime Type Information.
3. Operator overloading. This makes the language morphable which is killing
nearly the ability to understand code by reading it.
4. Syntactically hidden code paths
(exceptions, constructors with side effects, destructors which you never know
when they tis you...) make the readability even worser...
5. Instability of compiler implementations (ever wondered how many libstdc++ you
have on your linux system?)
On Tue, Apr 09, 2002 at 06:16:38AM -0400, T. A. wrote:
> I am in the initial stages of writing some C++ wrapper classes for the
> kernel.
[snip]
> Would patches be welcomed for one or more of these issues?
No. See http://www.tux.org/lkml/#s15-3 .
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635
Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
I would like to rewrite the kernel in FORTRAN because this was
one of the first languages I learned.
Seriously, the kernel MUST be written in a procedural language.
It is the mechanism by which something is accomplished that defines
an operating system kernel.
C++ is an object-oriented language, in fact the opposite of a
procedural language. It is not suitable.
Many so-called programmers look at kernel code and see that a
lot is written in 'C'. Then they think; "I can do this better
because I know C++. Everybody knows that C++ is better than
plain old C..."
If you really knew C++, you wouldn't even joke about putting it
in the kernel.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
* Richard B. Johnson ([email protected]) wrote:
>
> I would like to rewrite the kernel in FORTRAN because this was
> one of the first languages I learned.
>
> Seriously, the kernel MUST be written in a procedural language.
> It is the mechanism by which something is accomplished that defines
> an operating system kernel.
>
> C++ is an object-oriented language, in fact the opposite of a
> procedural language. It is not suitable.
Bollox!
There are many places in the kernel that are actually very OO - look at
filesystems for example. The super_operations sturcture is in effect a
virtual function table.
Sure making every file an object is probably OTT; but large scale things
like a filesystem, a network device or the like probably actually fit
very well.
Sure, there are a lot of features of C++ to stay clear of - exception
handling probably being one of them, and I wouldn't let the C++ stuff
anywhere near the memory management code.
Point being that it is a case of using the write tool for the job. C++
douesn't add any extra overhead just by calling it C++ and not using any
of the features; careful use of the features where appropriate does no
harm and might actually make the code cleaner, and possibly more
efficient.
I will agree going head in and just throwing C++ at it is a bad thing.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:
> * Richard B. Johnson ([email protected]) wrote:
> >
> > I would like to rewrite the kernel in FORTRAN because this was
> > one of the first languages I learned.
> >
> > Seriously, the kernel MUST be written in a procedural language.
> > It is the mechanism by which something is accomplished that defines
> > an operating system kernel.
> >
> > C++ is an object-oriented language, in fact the opposite of a
> > procedural language. It is not suitable.
>
> Bollox!
>
> There are many places in the kernel that are actually very OO - look at
> filesystems for example. The super_operations sturcture is in effect a
> virtual function table.
>
The file operations structure(s) are structures. They are not object-
oriented in any way, and they are certainly not virtual. The code that
manipulates them is quite physical and procedural, well defined, and
visible to the rest of the kernel.
> Sure making every file an object is probably OTT; but large scale things
> like a filesystem, a network device or the like probably actually fit
> very well.
Err. From the outside-in, any well-defined software functionality
can look like an "object". In fact, any well-defined and well functioning
software is indistinguishable from magic, therefore can be represented
as an object in the true object-oriented sense.
>
> Sure, there are a lot of features of C++ to stay clear of - exception
> handling probably being one of them, and I wouldn't let the C++ stuff
> anywhere near the memory management code.
>
C++ is designed for user-mode programming. It expects to interface
with a complete operating system with well-defined characteristics.
It is not designed to be part of an operating system kernel.
> Point being that it is a case of using the write tool for the job. C++
> douesn't add any extra overhead just by calling it C++ and not using any
> of the features; careful use of the features where appropriate does no
> harm and might actually make the code cleaner, and possibly more
> efficient.
>
It is quite unlikely that a C++ compiler will make more efficient
code than a C compiler. In fact, the code generator will likely
be the same. The C++ compiler will end up generating some preamble
code as part of the function-calling mechanism, that is not necessary
in C. This means that it will generate a bit more code.
Making code "cleaner" is a matter of perspective.
class A {
public: void func(char *st) { cout << st << endl; }
};
using A::func;
A a;
a.func("Hello World!");
Is not all that clean. In fact, I'm not sure I have it right. It's
easier and clearer to write puts("Hello World!");
> I will agree going head in and just throwing C++ at it is a bad thing.
>
> Dave
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
"Richard B. Johnson" wrote:
>
> On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:
> > There are many places in the kernel that are actually very OO - look at
> > filesystems for example. The super_operations sturcture is in effect a
> > virtual function table.
>
> The file operations structure(s) are structures. They are not object-
> oriented in any way, and they are certainly not virtual. The code that
> manipulates them is quite physical and procedural, well defined, and
> visible to the rest of the kernel.
I disagree. A filesystem has a certain set of semantics. There are numerous
types of filesystems, each of which implements that set of semantics (and
possibly additional ones as well) in a different way. This is a classic example
of a situation where oo style programming can be useful. There are many cases
where C code is in essence implementing virtual functions using function
pointers. C++ allows the compiler to do the hard work of keeping track of the
virtual functions.
> It is quite unlikely that a C++ compiler will make more efficient
> code than a C compiler. In fact, the code generator will likely
> be the same. The C++ compiler will end up generating some preamble
> code as part of the function-calling mechanism, that is not necessary
> in C. This means that it will generate a bit more code.
C++ has tigher constraints on code than C. This can allow a compiler to
generate better code because it has more knowledge about what is going on.
> Making code "cleaner" is a matter of perspective.
>
> class A {
> public: void func(char *st) { cout << st << endl; }
> };
> using A::func;
> A a;
> a.func("Hello World!");
>
> Is not all that clean. In fact, I'm not sure I have it right. It's
> easier and clearer to write puts("Hello World!");
Your example is needlessly complex, and I'm sure you know this. A more
realistic comparison would be:
cout << "Hello World!\n";
Now I don't for a moment think that we should go and convert everything to C++.
But I do think that certain features of the language can be useful, and that
there are cases when OO style programming makes the code easier to read and
understand.
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
commence Chris Friesen quotation:
> "Richard B. Johnson" wrote:
>> Making code "cleaner" is a matter of perspective.
>>
>> class A {
>> public: void func(char *st) { cout << st << endl; }
>> };
>> using A::func;
>> A a;
>> a.func("Hello World!");
>>
>> Is not all that clean. In fact, I'm not sure I have it right. It's
>> easier and clearer to write puts("Hello World!");
>
> Your example is needlessly complex, and I'm sure you know this. A more
> realistic comparison would be:
>
> cout << "Hello World!\n";
And of course standard libraries are not available in the kernel, so
you'll most likely end up calling printk anyway in your C++ kernel
code.
--
///////////////// | | The spark of a pin
<[email protected]> | (require 'gnu) | dropping, falling feather-like.
\\\\\\\\\\\\\\\\\ | | There is too much noise.
On Tue, 9 Apr 2002, Sean Neakums wrote:
[snip]
Guys, take it somewhere else. See l-k FAQ for reasons.
On Tuesday, April 9, 2002, at 09:28 PM, Richard B. Johnson wrote:
> C++ is designed for user-mode programming. It expects to interface
> with a complete operating system with well-defined characteristics.
> It is not designed to be part of an operating system kernel.
Not according to Apple.
http://developer.apple.com/techpubs/macosx/Darwin/IOKit/iokit.html
"The I/O Kit is a collection of system frameworks, libraries, tools,
and other resources for creating device drivers in Mac OS X. It is
based on an object-oriented programming model implemented in a
restricted form of C++ that omits features unsuitable for use within
a multithreaded kernel."
Although I wouldn't use this as a justification for doing this
in Linux ;).
~mc
On Tue, 9 Apr 2002, Richard B. Johnson wrote:
> On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:
> > There are many places in the kernel that are actually very OO - look at
> > filesystems for example. The super_operations sturcture is in effect a
> > virtual function table.
>
> The file operations structure(s) are structures. They are not object-
> oriented in any way, and they are certainly not virtual. The code that
> manipulates them is quite physical and procedural, well defined, and
> visible to the rest of the kernel.
As Alan said it very nicely one day:
"Object orientation is in the mind, not in the compiler"
What we want is some (sane) degree of abstraction so things stay
maintainable, we don't need a full rewrite in another language.
regards,
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
Scribbling feverishly on April 09, T. A. managed to emit:
> Hi all,
>
> I am in the initial stages of writing some C++ wrapper classes for the
> kernel. So far its been an interesting process, mainly due to the use of
Stop right here, read http://www.tux.org/lkml/#s15-3, and figure out
what you've done wrong. ;-)
> Would patches be welcomed for one or more of these issues?
I dare say not. One wonders if this message was a carefully crafted
troll.
Kurt
--
Ships are safe in harbor, but they were never meant to stay there.
>>>>> "Chris" == Chris Friesen <[email protected]> writes:
>> It is quite unlikely that a C++ compiler will make more
>> efficient code than a C compiler. In fact, the code generator
>> will likely be the same. The C++ compiler will end up
>> generating some preamble code as part of the function-calling
>> mechanism, that is not necessary in C. This means that it will
>> generate a bit more code.
Chris> C++ has tigher constraints on code than C. This can allow
Chris> a compiler to generate better code because it has more
Chris> knowledge about what is going on.
There are also many GNU extensions to C that makes it possible to
generate better code, e.g. marking certain functions as pure
functions.
Chris> Your example is needlessly complex, and I'm sure you know
Chris> this. A more realistic comparison would be:
Chris> cout << "Hello World!\n";
This has demonstrated that you don't know C++ _very_ well. Instead of
the trailing "\n", a C++ programemr ought to write:
cout << "Hello World!" << endl;
You seem to *understand* C++ even worse than Richard. Even Richard
used "endl" in his unnecessarily complex example. And you're not a
better programmer, either, because you failed to distill out the EOL
concept and represent it in an abstract, OS/platform-independent way.
Chris> Now I don't for a moment think that we should go and
Chris> convert everything to = C++.=20 But I do think that certain
Chris> features of the language can be useful, and tha= t there
Chris> are cases when OO style programming makes the code easier
Chris> to read and understand.
I don't find the current Linux fs code is too difficult to understand,
although it is doing OO in a non-OO language. Rather, I think this is
easier to maintain, because you don't have to go through all the
burdens of writing the C++ code. (It's easy to get a working C++ code
work. But making it efficient (e.g. sprinking "const" to wherever
possible so that it becomes a potential for the compiler to do
optimization) and *flawless* (e.g. multithread-safe, reentrant,
SMP-safe, **side-effect-less**, privatizing all dangerous copy
constructors as well as assignment operators, no memory leakage...)
would be very devoting. The time could better be spent on the C
code.)
Unless the FS code gets the complexity comparable to Xt (tall
inheritance trees), I don't think the overhead of doing it in C++
worths. (Xt is still bearable when used as a user. But if you try to
extend it (by writing a few custom widget classes) or maintain code in
it, you'd wish it were in C++.) How deep would the FS code grow to?
If it is shallow, then IMO, don't do it in C++; you'll be spending
more time for the cosmetics than really getting advantage out of it.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
>>>>> "Richard" == Richard B Johnson <[email protected]> writes:
Richard> On Tue, 9 Apr 2002, Dr. David Alan Gilbert wrote:
>> * Richard B. Johnson ([email protected]) wrote:
>> I would like to rewrite the kernel in FORTRAN because this was
>> one of the first languages I learned. Seriously, the
>> kernel MUST be written in a procedural language. It is the
>> mechanism by which something is accomplished that defines an
>> operating system kernel. C++ is an object-oriented
>> language, in fact the opposite of a procedural language. It
>> is not suitable. Bollox! There are many places in the
>> kernel that are actually very OO - look at filesystems for
>> example. The super_operations sturcture is in effect a virtual
>> function table.
Richard> The file operations structure(s) are structures. They are
Richard> not object- oriented in any way, and they are certainly
Richard> not virtual.
The term "virtual" has a very specific in OO, esp. in C++.
Unfortunately, this word isn't a very faithful description of what it
means. Java uses the keyword "abstract" for what is "virtual" in C++.
This is much more appropriate.
And "virtual function table", "vptr", "vtable" are also specific terms
in OO which refer to implementation details of the run-time of an OO
language. To you, this shouldn't be anything new. A "virtual
function table" is just an array of pointers to functions. It serves
essentially the same purpose as the super_operations structure in the
Linux kernel. Instead of having to building the table (in source
code, not run-time) yourself, the compiler of C++ and any OO language
would do it for you automatically, thereby saving typing effort and
avoiding trivial typos.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On 9 Apr 2002, Sau Dan Lee wrote:
[SNIPPED ... all]
We need to take this off linux-kernel. Anybody who wants to
continue, please contact me directly. No Holy Wars. I know
that everybody I have communicated with has good points to
ponder.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
Who the heck said anything about rewriting the kernel? I'm just looking
into coding a C++ framework for those whom may like to use it in modules,
mostly for hack value.
And yes I do know C++ and it can very well be used for low level stuff
such as the kernel. Now that doesn't mean I'm going to go wild and start
writing extensive templates, exceptions, standard template libraries, or any
of the other unneeded crap (mostly from the last C++ revision) either.
And as far as the comment of being a troll goes I could definitely find
better uses of my time. Only reason for a post here is because I'm looking
for some guidance on a couple of minor issues I've encountered. The C
brigades can go back and rest in the barracks now.
----- Original Message -----
From: "Richard B. Johnson" <[email protected]>
To: "Martin Dalecki" <[email protected]>
Cc: "T. A." <[email protected]>; "Linux Kernel Mailing List"
<[email protected]>
Sent: Tuesday, April 09, 2002 8:10 AM
Subject: Re: C++ and the kernel
>
> I would like to rewrite the kernel in FORTRAN because this was
> one of the first languages I learned.
>> snip <<
> If you really knew C++, you wouldn't even joke about putting it
> in the kernel.
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>
> Windows-2000/Professional isn't.
>
>
----- Original Message -----
From: "Kurt Wall" <[email protected]>
To: "T. A." <[email protected]>
Sent: Tuesday, April 09, 2002 12:16 PM
Subject: Re: C++ and the kernel
> Scribbling feverishly on April 09, T. A. managed to emit:
> > Hi all,
> >
> > I am in the initial stages of writing some C++ wrapper classes for
the
> > kernel. So far its been an interesting process, mainly due to the use
of
>
> Stop right here, read http://www.tux.org/lkml/#s15-3, and figure out
> what you've done wrong. ;-)
>
> > Would patches be welcomed for one or more of these issues?
>
> I dare say not. One wonders if this message was a carefully crafted
> troll.
>
> Kurt
> --
> You will reach the highest possible point in your business or profession.
>
----- Original Message -----
From: "Martin Dalecki" <[email protected]>
To: "T. A." <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
Sent: Tuesday, April 09, 2002 5:54 AM
Subject: Re: C++ and the kernel
> > So far my overloading of "new" works if I compile the module without
> > exceptions (-fno-exceptions). This is fine for myself as I prefer
checking
>> snip <<
> > include exception support if possible so those whom may want to use it,
>
> This will turn out to be nearly impossible. Please note that
> the exception mechanisms in C++ are basically a second function
> return path and are therefore not desirable at all for the following
reasons:
>
> 1. It's silly becouse we have already a return path and page fault based
> exception mechanisms in kernel, which is far better suited for the
purposes
> of the kernel then the C++ semantics. (Remarkable the KDE people
recognize
> that C++ exceptions are not a good thing...)
>
> 2. It's changing the stack layout for the kernel functions, and there
> are few of them which rely on a particular stack layout (namely the
> scheduler and some *.S files - look out for the asmlinkage
attribute...)
Well I don't really need (or like) exceptions so forgetting about them
works for me. However currently there is no other efficient means of
determining if an error has occured during a objects construction. No
return value. Would have to waste memory on a flag variable. Would the
above problems also be present on the module level? I don't really want
exceptions leaving the module, so to speak.
> >
> > int init_module()
__attribute__((alias(mangle_name("load__9my_module"))));
> > int cleanup_module()
> > __attribute__((alias(mangle_name("unload__9my_module"))));
>
> I guess the above wouldn't work due to the games which the linkage scripts
> play already on the init_module and cleanup_module function.
> Maybe you would rather wan't to have a look at those scripts themself
> and adjust them accordingly? (Possibly having a mangling tool at hand...)
Do you mean the module_[init|exit] macros? If so I've already taken a
look at them. Thats where I got the alias from. And the above does work.
However currently I have to compile the module, do nm on it, find the magled
name, and enter it manually as above; then recompile. Works though.
> > my_module mod1;
>
> Well the "hidden C++" initializations you should propably forget
> about - they are not desirable inside the kernel, becouse this
> C++ mechanism is annihilating the expliciticity of the programm controll
> flow of C.
Oh well works for me. Pointers to objects will get the job done.
> > Would patches be welcomed for one or more of these issues?
>
> Personally I would just like to have the ability to compile the
> kernel with C++ just for the following two reaons:
>
> 1. C++ is a bit tighter on type checking, which would give better
regreesions.
>
> 2. Modern GCC versions generate generally better code for C if compiled as
C++
> files, since the language gives tighter semantics to some constructs.
>
> However I wouldn't for certainly like to see the kernel beeing transformed
> in to C++. Expierence has shown over time that the chances for abuse of
this
> programming language are just too high. Language design idiocies like the
> following come immediately in to mind:
>
> 1. Templates.
>
> 2. Runtime Type Information.
>
> 3. Operator overloading. This makes the language morphable which is
killing
> nearly the ability to understand code by reading it.
>
> 4. Syntactically hidden code paths
> (exceptions, constructors with side effects, destructors which you never
know
> when they tis you...) make the readability even worser...
>
> 5. Instability of compiler implementations (ever wondered how many
libstdc++ you
> have on your linux system?)
Don't worry, not looking to do a C++ rewrite. Just looking to be able
to setup a C++ framework for use in modules.
From: "T. A." <[email protected]>
> Who the heck said anything about rewriting the kernel? I'm just looking
> into coding a C++ framework for those whom may like to use it in modules,
> mostly for hack value.
May I humbly suggest that this list is not a good place for this discussion.
Attitudes are quite ossified for many good reasons and probably a few bad
reasons. Take a reasonably cleanly functioning kernel as a tool and develop
a fully C++ kernel. Try it out. Benchmark it for size and speed. Report back
comparisons with its original base.
You are sounding like a little boy who has found a new toy. Over 40 years of
experience suggests the proper way to handle this is to let the person have
his head, and in the corporate world some IR&D funds, to develop a project
that uses the idea and report back in detail how it worked out. If it succeeds
the company or group wins. If it fails it managed to stay out of your product
stream, for as sure as the Sun generally rises roughly in the East it WILL
find its way into something as the person's way of finding out for himself if
it works.
This is an issue that has caused this list a significant amount of distraction
over the years. Maybe it would be a really good thing to develop numbers and
data to either support it or shoot it down. The cant of a Computer Science
cirrocumuli often fails when the rubber meets the road. This may and may not
be such. I trust the kernel maintainers' instincts in this regard. Old age
and experience will beat youth and enthusiasm any day in the long run.
So take a team with you, select a dictator or leader or whatever, and simply
make a rigid translation of a kernel snapshot to C++ without adding any new
functionality. Let us all watch the progress, say on SourceForge or the like.
And report back when it is all done. You may be right that it is something
that is worth doing. But, unless you can show in very hard data that there is
a real advantage to C++ in the kernel Linus will simply reject it with the
full support of the rest of his crew.
FWIW, Microsoft does not use C++ in their kernel.
{^_^}
On Tue, 9 Apr 2002, J. Dow wrote:
> From: "T. A." <[email protected]>
>
> > Who the heck said anything about rewriting the kernel? I'm just looking
> > into coding a C++ framework for those whom may like to use it in modules,
> > mostly for hack value.
>
> May I humbly suggest that this list is not a good place for this discussion.
> Attitudes are quite ossified for many good reasons and probably a few bad
> reasons...
I hate to get into this discussion(1)... but could you at least read a
little bit beyond the subject line before answering. The bits like "who that
heck said anything about rewriting the kernel?" and "hack value"...
Rui Sousa
(1) Yeah, ok I did it any way.
Followup to: <[email protected]>
By author: "Richard B. Johnson" <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > Bollox!
> >
> > There are many places in the kernel that are actually very OO - look at
> > filesystems for example. The super_operations sturcture is in effect a
> > virtual function table.
>
> The file operations structure(s) are structures. They are not object-
> oriented in any way, and they are certainly not virtual. The code that
> manipulates them is quite physical and procedural, well defined, and
> visible to the rest of the kernel.
>
Again, bollocks. The file operation structures are vanilla vtbl
implementations of virtual functions. The fact that they're written
foo->f_ops->func(foo, ...);
instead of
foo->func(...);
makes absolutely no difference whatsoever.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>