Linux-Development-Sys Digest #327
Linux-Development-Sys Digest #327, Volume #8 Wed, 6 Dec 00 12:13:13 EST
Contents:
Re: c++ in kernel and linker problems (Kaz Kylheku)
Re: kernel header problems (Kaz Kylheku)
Macro question (Arnaud Westenberg)
Re: Please help: NT to Linux port (Kaz Kylheku)
Re: c++ in kernel and linker problems (Mathias Waack)
warning: cast from pointer (Dr. Unk)
warning: cast from pointer (Dr. Unk)
Re: warning: cast from pointer (Richard Heathfield)
Re: Module Compilation Problems ("Peter T. Breuer")
Re: Development Environments (rob@--)
Re: Why is ramdisk always 4 MB? ([EMAIL PROTECTED])
TCP Retransmission Timeout Value (Johan)
Re: Toronto, Kylix is coming! (Nix)
Re: how to rebuild tcp code (Nix)
Re: warning: cast from pointer (Dan Pop)
Re: linuxthread manager and SIGINT ("Arthur H. Gold")
Re: Getting eth0 device information in C or perl. (Dave Blake)
Re: Toronto, Kylix is coming! (bgeer)
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: c++ in kernel and linker problems
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Dec 2000 09:40:07 GMT
On Tue, 05 Dec 2000 08:40:04 +0100, O.Petzold [EMAIL PROTECTED] wrote:
Hello,
I try to write C++ for a linux kernel module, since I use the same code
for the real app und the module. The problem is, I can't use exceptions
and rtti, so I have to emulate this. The first I use a global flag, the
2nd - no
idea. Well, I have now linking problems - I get:
no_xception_test.o: unresolved symbol __vt_9bad_alloc
no_xception_test.o: unresolved symbol _._9bad_alloc
no_xception_test.o: unresolved symbol __9exception
no_xception_test.o: unresolved symbol __vn__FUiRC9nothrow_t
no_xception_test.o: unresolved symbol nothrow
vt stands for virtual table - I guess this all is from name mangeling.
I use THROW(std::bad_alloc) inside the construct
You cannot use components from the C++ standard library in the kernel;
that library is not available. Only a very small subset of the C library
is there, never mind C++.
You will find that even if you thrown your own exception type, it will not
work. You see, exception handling requires considerable run-time support, int
the form of special functions that are in libgcc.a. This would have to be
ported to the kernel. So unless you are willing to do that work, you can
forget about C++ exception handling in the kernel.
Also do you really need RTTI? In well structured code, certainly the kind of
code that belongs in an operating system kernel, you should not have to use
this at all. Instead of asking an object what type it is and take special
action, you should be able to just not care, and simply use the uniform
interface of its base class methods.
A bigger problem you are facing is the rampant use of C++ keywords in the
kernel's header files: class, namespace, public, you name it.
My recommendation is that you make a header "hidekeywords.h" which defines
macros that have the same spelling as C++ keywords, and expand to identifiers
which are not C++ keywords, e.g:
#define class cpp_class
#define virtual cpp_virtual
Also create another another header which #undefs all these macros, so that you
can do, at the top of your C++ file:
#include "hidekeywords.h"
extern "C" {
#include linux/kernel/headers.h
}
#include "restorekeywords.h"
How can I write the classes nothrow, exception
and
bad_alloc so that I don't get linker errors ?
Since you don't have exception handling, you have no use for these. Write your
operator new so that it just returns null when there is no memory and use
traditional error handling.
--
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kernel header problems
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Dec 2000 09:54:26 GMT
On Wed, 06 Dec 2000 09:57:50 +0100, O.Petzold [EMAIL PROTECTED] wrote:
/usr/src/linux/include/linux/signal.h:159: warning: assignment of negative
value `-1' to `long unsigned int'
There is nothing wrong with this assignment. To anyone with half a clue in
C or C++ programming, it's a familiar idiom for the maximum value of the
unsigned type. I find warnings like this to be extremely annoying.
Just ignore it.
- case 1:
+ case 1: return;
Or just a semicolon would do; the label needs to be followed by a statement.
This switch statement is taking advantage of a gratuitous GNU C extension. I'm
surprised that the same extension is not available in GNU C++.
With -pedantic, gcc will catch this error in C code: ``warning: ANSI C forbids
label at end of compound statement''. Maybe the kernel headers should
first be cleaned up so that they pass -pedantic when compiled as C.
It's interesting to have the same errors with gcc and g++!
That's because you are using the C++ compiler in both cases. The .cc suffix
of your base source file determines that.
--
Linux-Development-Sys Digest #327
Linux-Development-Sys Digest #327, Volume #6 Mon, 25 Jan 99 03:14:32 EST
Contents:
Re: Linux Phase 2: A Consumer Operating System (David Magda)
Re: Linux Phase 2: A Consumer Operating System (Christopher B. Browne)
Re: TAO: the ultimate OS (Miguel Cruz)
Re: TAO: the ultimate OS ("jdn")
Dissassemble bootsection (Dennis Wetzig)
Re: Linux ext2 dump (Leslie Mikesell)
Re: D-Link NIC driver, anyone? (Mark Hahn)
Re: Comparison of Swing, Qt, GTk? (BL)
Compiling gcc fails at stage1 (Matthew Vanecek)
From a Vritual Server to a Colocate ("Mr. Poet")
Re: Modest next goal for Linux (John De Hoog)
From a Virtual Server to a Colocate ("Mr. Poet")
Re: Modest next goal for Linux (Leslie Mikesell)
Re: Autofs automounter auto.direct (Jamie Guinan)
Re: Compiling gcc fails at stage1 (Loren Osborn)
Re: LILO and 10 GB drives ("wÕÕg")
Re: Attention Linux Programmers! ("Aaron Drew")
Re: disheartened gnome developer (Michael Powe)
From: [EMAIL PROTECTED] (David Magda)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Linux Phase 2: A Consumer Operating System
Date: 23 Jan 1999 23:15:13 GMT
[EMAIL PROTECTED] (Christopher Browne) writes:
The point is that if interesting pieces of the system "solidify" to the
point that people can't change them without causing immense breakage,
then it's no longer fun playing with those pieces.
Well I'm sure someone will come along and make a distribution that's similiar
to what FreeBSD and all do. Have a ports section and instead of worrying about
RPMs et al. just go into a specific directory and to `make update` and have
everything you need sorted out. Suppposedly Debian does this?
At some point, it becomes more difficult to get a change in than it is
to say "Screw it, I'm using another system where I can do what I like,
and have a bit more control."
Isn't that why the source code is available? So you can play with it yourself?
All (most?) the new features first started out as patches and later were
added to the kernel as part of the 2.1.x series. The NTFS modules started
like this.
We can see a certain degree of "ossification" taking place already with
the Linux kernel. It used to be about a year between major new even
versions. The "time betweeen releases" is increasing. And there are
enough big plans coming up in the 2.3 series to give ample opportunity
for it to be 2001 or later until a 2.4 release.
But there is also more code to manage and debug. What's the size of 1.2
versus 2.0 versus 2.2? You could also argue that 1.2 had the more basic,
easier to code/debug features and the later kernels are adding more features
that have a larger complexitity. Anyone know how hard will it be to encode
all the I20 and USB stuff?
The point was that the sorts of people that can build a system like
Linux may conclude it time to move on, which will mean that a great
creative element is taken away. It might be several years before
effects become really apparent.
They can always fork off like OpenBSD from NetBSD from FreeBSD. They could
also hack their own patches, they just might not go into the 2.3 series
"officially" (i.e., always stay as patches).
--
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Linux Phase 2: A Consumer Operating System
Reply-To: [EMAIL PROTECTED]
Date: Sun, 24 Jan 1999 00:49:00 GMT
On 23 Jan 1999 23:15:13 GMT, David Magda [EMAIL PROTECTED] posted:
[EMAIL PROTECTED] (Christopher Browne) writes:
The point is that if interesting pieces of the system "solidify" to the
point that people can't change them without causing immense breakage,
then it's no longer fun playing with those pieces.
Well I'm sure someone will come along and make a distribution that's similiar
to what FreeBSD and all do. Have a ports section and instead of worrying about
RPMs et al. just go into a specific directory and to `make update` and have
everything you need sorted out. Suppposedly Debian does this?
That's fair enough.
It would be interesting to see a distribution for Linux that had a
greater tendancy to work with source code (ala Ports) rather than treating
binaries as the thing that gets moved around.
A new system could certainly gain advantage from some existing tools and
even code. Which is pretty much why Hurd is trying to get a Debianized
version released, with the goal of hopefully being able to make use of
some of those thousands of .deb packages. (At this moment, it supports
33 of 'em.)
At some point, it becomes more difficult to get a change in than it is
to say "Screw it, I'm using another system where I can do what I like,
and have a bit more control."
Isn't that why t
