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.
------------------------------
Date: Wed, 06 Dec 2000 10:32:35 +0100
From: Arnaud Westenberg <[EMAIL PROTECTED]>
Subject: Macro question
Hi all,
I've some problems with the macro I've written. I'm using the macro to
determine the io address of hardware with a segmented memory map. Not
all hardware boards use a segmented memory map, so there's also a check
for a segmented flag.
/* Hardware specific flag in "chip" structure */
#define SEGMENTED (1U << 0)
/* Memory segments offset */
#define SPACING 0x3c0
/* Minor number of device (only used within file operations) */
#define MINOR_NR \
(MINOR(file->f_dentry->d_inode->i_rdev))
/* BASE(addr) should represent the absolute io address */
#define BASE(addr) \
((chip[MINOR]->chip_base_address) + \
((chip[MINOR]->flags & SEGMENTED) * SPACING * ((addr)>>6)) + \
(addr))
The addr argument is the io value of the unsegmented memory map wich
starts at 0x00. The second (BASE macro) line represents the base io
address of the particular chip. The third line (tries) to add a memory
offset based on the addr argument and the SEGMENTED flag. The bit
shifting of the addr argument is used to determine the memory segment.
The last line adds the unsegmented address.
For unsegmented hardware this macro works fine, but when SEGMENTED is
true the driver halts. The problem is the bit shifting of the addr
argument in the third line. When removing the bit shifting it also works
fine for segmented hardware (but obviously this is the wrong address).
Obviously I have to typecast the bit shifted term, but adding (int) to
the term doesn't help. Could someone please tell me the correct way to
typecast this term to integer form?
Thanks for your help.
Regards Arnaud
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Please help: NT to Linux port
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Dec 2000 09:56:41 GMT
On Wed, 6 Dec 2000 10:21:55 +0200, Andrew Voznytsa <[EMAIL PROTECTED]> wrote:
>I never did it, but I know some things which can help you,
>It's not very hard but it also I not very easy,
It also won't work.
>in two words:
>
>1. you should install sig. handler;
>2. when handler will be called, it should call __throw(); (this functions
>generates throw, sources is in <gcc root>/gcc/libgcc2.c, also in this file
That's backwards. __throw should never be called explicitly. It's the throw
operator which causes __throw to be called internally.
You cannot throw C++ exceptions out of signal handlers, currently. Linux's
signal stack will confuse __throw.
As an alternative, consider using longjmp() to jump out of the handler.
The setjmp() block can then churn out an exception.
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: c++ in kernel and linker problems
Date: 06 Dec 2000 11:14:45 +0100
"O.Petzold" <[EMAIL PROTECTED]> writes:
> like this ?: class A {
> A();
> ~A();
> virtual int type() { return unique_id; }
> };
Yes.
> So I can use dynamic_cast and typeid (typeinfo.h) ?
No. (This requires runtime support which is not available.)
> > > The nothrow symbol is defined inside header new with extern const
> > >nothrow_t nothrow;
> > Thats a declaration, not a definition. Are you sure that nothrow is
> >defined somewhere?
>
> Yes, in my code - see above: char* p = new(nothrow) char[39]; With
> this I can proof on (!p) for user and kernel space. The other way
> could
I still can't see any definition.
> No use of the c++ includes from kernel space?, so I have to write my
> own kernel libstc++ ?
If you use it you have to write it.
But in most cases there is no need for this. See the solution above or
read what Kaz says.
Mathias
------------------------------
From: Dr. Unk <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.os.linux.alpha
Subject: warning: cast from pointer
Date: Wed, 06 Dec 2000 11:12:18 GMT
I would like know how to clean up a source, so that I do not get any
more "warning: cast from pointer to integer of different size" or
"incompatible pointer" warnings. I know that in most cases they are
just that, warnings. But sometimes, I believe them to be the cause if
many seg faults and floating point exceptions.
My C knowledge is basic-level (2 courses taken). My system is an
AlphaPC 164SX, Glibc-2.1.3, GCC-2.95.2, Linux-2.2.17.
Thanks in advance.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dr. Unk <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.os.linux.alpha
Subject: warning: cast from pointer
Date: Wed, 06 Dec 2000 11:12:44 GMT
I would like know how to clean up a source, so that I do not get any
more "warning: cast from pointer to integer of different size" or
"incompatible pointer" warnings. I know that in most cases they are
just that, warnings. But sometimes, I believe them to be the cause if
many seg faults and floating point exceptions.
My C knowledge is basic-level (2 courses taken). My system is an
AlphaPC 164SX, Glibc-2.1.3, GCC-2.95.2, Linux-2.2.17.
Thanks in advance.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 06 Dec 2000 11:23:53 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: warning: cast from pointer
"Dr. Unk" wrote:
>
> I would like know how to clean up a source, so that I do not get any
> more "warning: cast from pointer to integer of different size" or
> "incompatible pointer" warnings. I know that in most cases they are
> just that, warnings. But sometimes, I believe them to be the cause if
> many seg faults and floating point exceptions.
>
> My C knowledge is basic-level (2 courses taken). My system is an
> AlphaPC 164SX, Glibc-2.1.3, GCC-2.95.2, Linux-2.2.17.
Please post a short C program which produces such a diagnostic. Then we
can help you fix it.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Wed, 6 Dec 2000 12:19:59 +0100
Brian <[EMAIL PROTECTED]> wrote:
[in the wrong place - reformatted]
> "Peter T. Breuer" <[EMAIL PROTECTED]> news:[EMAIL PROTECTED]...
>> Brian <[EMAIL PROTECTED]> wrote:
>> > The directory /usr/include/linux is a real one containing lots of header
>> > files in RedHat 7.0. You cannot directly restore the link. I don't know why
>> > RedHat made this reconstruction, but I think it's better to keep it there.
>>
>> Why do you think so? It's wrong. The directory is only there to give
>> you some kernel header files in case you don't have any. But he has
>> plenty, and he can link to them all. And thus avoid doing kernel
> Perhaps I'm not doing it the professional way. But it just sounds strange to
> me that I have to delete the system files supplied by the distributor in
> order to restore the link.
It's a physical fact that two objects canot occupy the same space. You
can move the directory to not-linux if you prefer, instead of deleting
it! Then move it back later. Or you can keep the fixed directory they
suplied with the old kernel headers and modify your makefile to point
to the real kernel sources.
RHs change is apparently to keep hold of at least some kernel headers
that they know are in a working state, so that they don't get blamed
when linus goofs (intentionally or otherwise). Then the kernel includes
that some of the libc headers still need can be guaranteed to be
unmunged.
I just don't see this as a real problem. Sorry redhat. Your users
aren't the kind who go around dropping in random kernel sources. And
if they are, they know what to do about it if things go haywire.
And they won't, because it's a libc problem if they do, not a kernel
problem.
Peter
------------------------------
From: rob@-- <[EMAIL PROTECTED]>
Subject: Re: Development Environments
Date: 6 Dec 2000 03:46:19 -0800
In article <90i2u3$hme$[EMAIL PROTECTED]>, "Guy says...
>
>With development environmet i mean in fact an IDE.
You can try Borland JBuilder. There is a free download version
to try, I think it is called something 'Foundation' .... check
http://www.borland.com. There is also other IDE's for Java
on linux such as Sun Forte, also IBM has a Java IDE for Linux.
I think JBuilder is probably the best, but you have to decide
for yourself.
Rob
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why is ramdisk always 4 MB?
Date: Wed, 06 Dec 2000 12:54:18 -0000
(when you) Upgrade to 2.4, try out the ramfs facility.
On Tue, 05 Dec 2000 23:16:00 -0700 John Kelly <[EMAIL PROTECTED]> wrote:
| Never mind. The problem was inodes, not disk size.
|
| -jk
|
|
| John Kelly wrote:
|
|> I've compiled 2.2.16 on RH7 with modular ramdisk support, and booted the
|> image with ramdisk=56000 (on
|> a machine with 256MB RAM). I do an insmod rd rd_size=56000, and get a
|> success message in /var/log/messages.
|>
|> mkfs -t ext2 /dev/ramdisk succeeds, and says that 56000 blocks were
|> found,
|>
|> mount /dev/ramdisk /mnt/ramdisk works.
|> df -k /dev/ramdisk shows about 56MB availible,
|>
|> BUT.....
|>
|> if I copy more than 4MB into the ram fs, I always get a disk full
|> message.
|>
|> What am I doing wrong?
|>
|> =jk
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Johan <[EMAIL PROTECTED]>
Subject: TCP Retransmission Timeout Value
Date: Wed, 06 Dec 2000 14:12:55 +0100
Hi,
I'm wondering if someone knows how to get the current TCP RTO value used
when sending TCP packets.
/Johan
------------------------------
From: Nix <$}xinix{$@esperi.demon.co.uk>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Toronto, Kylix is coming!
Date: 06 Dec 2000 07:31:36 +0000
"TDUG" <[EMAIL PROTECTED]> writes:
> Kylix* is coming! And you probably have questions about the exciting new
> Borland Linux development tool that combines the Rapid Application
> Development (RAD) benefits of visual component based design, with the power
> of an optimizing native code compiler. No such application development tool
> exists for Linux today,
... because we don't like to reinvent the wheel. Why combine an IDE with
a compiler, of all things? Why not throw in a debugger, a shell, a
filesystems checker and a kitchen sink, all tightly integrated so you
can't use one without being forced to use all the rest as well, and all
nicely closed-source.
Oh yes. Just what we want.
(Disclaimer: I (once) liked Borland's IDEs. But the `oh yes let's pile a
compiler in there too' philosophy simply sucks.)
(Let's discount Emacs here. Not even Emacs has tried to rewrite GCC in
Lisp.)
--
`Get your acts together, guys. Stop blathering and frothing
at the mouth.' --- Linus Torvalds
------------------------------
From: Nix <$}xinix{$@esperi.demon.co.uk>
Subject: Re: how to rebuild tcp code
Date: 06 Dec 2000 07:34:19 +0000
Andi Kleen <[EMAIL PROTECTED]> writes:
> There is nothing like a "restart" in Linux networking.
In any case, he asked about restarting the *network*. And yes, you can
do that. You run around and pull all the network cables out of all the
machines on the subnet, then run around putting them all back in
again. This restarts the physical network.
It doesn't do any *good* to anything, but it restarts the network.
--
`Get your acts together, guys. Stop blathering and frothing
at the mouth.' --- Linus Torvalds
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c,comp.os.linux.alpha
Subject: Re: warning: cast from pointer
Date: 6 Dec 2000 15:14:54 GMT
In <90l6uf$v8h$[EMAIL PROTECTED]> Dr. Unk <[EMAIL PROTECTED]> writes:
>I would like know how to clean up a source, so that I do not get any
>more "warning: cast from pointer to integer of different size" or
>"incompatible pointer" warnings. I know that in most cases they are
>just that, warnings.
They *always* indicate bugs in your code. If your code "works", it is
purely by accident.
>But sometimes, I believe them to be the cause if
>many seg faults and floating point exceptions.
Indeed.
>My C knowledge is basic-level (2 courses taken). My system is an
>AlphaPC 164SX, Glibc-2.1.3, GCC-2.95.2, Linux-2.2.17.
Make sure that you include the required headers for *all* the library
functions you're calling and that you declare *all* your functions before
calling them.
Example of buggy code giving the diagnostic mentioned above on Alpha:
ues5:~/tmp 333> cat test.c
int main()
{
char *p = (char *)malloc(100); /* malloc *requires* <stdlib.h> */
return 0;
}
ues5:~/tmp 334> gcc test.c
test.c: In function `main':
test.c:3: warning: cast to pointer from integer of different size
ues5:~/tmp 335> gcc -Wall test.c
test.c: In function `main':
test.c:3: warning: implicit declaration of function `malloc'
test.c:3: warning: cast to pointer from integer of different size
test.c:3: warning: unused variable `p'
As you can see, -Wall also told you what is the exact problem triggering
the other warning. You *really* should get your code to compile cleanly
with gcc -Wall.
The right way to fix my example is to:
1. Include <stdlib.h>
2. Drop the cast in front of malloc. This cast will give a clean
compile (if you don't use -Wall) on a 32-bit platform, masking the
bug in the code.
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
Date: Tue, 05 Dec 2000 12:14:51 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: linuxthread manager and SIGINT
[EMAIL PROTECTED] wrote:
>
> I am running a linuxthreaded application. When I try
> to send SIGINT to the manager thread using kill it never gets *sent*.
> However if I try the same with say SIGSTOP it gets sent.
>
> Does anyone know why this is??
>
> Thank you,
Sure.
The signal gets "sent", all right, but it's explicitly
blocked by the manager thread.
[Of course, a quick perusal of the source would have told
you that.]
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"Curiousity didn't kill _this_ cat"
-- Studs Terkel, upon being asked what he thinks his epitaph
should be.
------------------------------
From: [EMAIL PROTECTED] (Dave Blake)
Crossposted-To:
aus.computers.linux,comp.os.linux.development.apps,comp.os.linux.networking,linux.dev.apps,linux.dev.c-programming,linux.dev.net
Subject: Re: Getting eth0 device information in C or perl.
Date: 6 Dec 2000 15:08:07 GMT
Reply-To: [EMAIL PROTECTED]
Joel Pobar <[EMAIL PROTECTED]> wrote:
> I need to get the IP address from eth0 in a C or Perl program.
> I was wondering if there are any functions that can be called
> to obtain this information.
Since this is an open source operating system, you could look
for the source to ifconfig or perhaps hostname.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (bgeer)
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Toronto, Kylix is coming!
Date: 6 Dec 2000 09:43:23 -0700
Nix <$}xinix{$@esperi.demon.co.uk> writes:
>"TDUG" <[EMAIL PROTECTED]> writes:
>> Kylix* is coming! And you probably have questions about the exciting new
>> Borland Linux development tool that combines the Rapid Application
>> Development (RAD) benefits of visual component based design, with the power
>> of an optimizing native code compiler. No such application development tool
>> exists for Linux today,
>... because we don't like to reinvent the wheel. Why combine an IDE with
>a compiler, of all things? Why not throw in a debugger, a shell, a
>filesystems checker and a kitchen sink, all tightly integrated so you
>can't use one without being forced to use all the rest as well, and all
>nicely closed-source.
Hmmmmm...let's think about this a little bit...I run 2 xterms & emacs,
I edit in one window, move the mouse a little bit & type "make", move
the mouse a little more & run gdb. Ok, tell me again how an IDE makes
this so much easier?
Ok, now add the challenge of making a few minor adjustments to a
project you worked on 2 years ago. Xterm, emacs, make, gcc, & gdb all
work pretty much the same. Will the latest version of the IDE even
load the old project material???
Now, port your project to Solaris or Digital Unix - does the IDE even
work there???
& don't even THINK of getting me started on YACT - yet another case tool!!!
ARRRGGGGGGGGGHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--
<> Robert Geer & Donna Tomky | |||| |||| <>
<> [EMAIL PROTECTED] | == == Suddenly, == == <>
<> [EMAIL PROTECTED] | == == We feel enchanted! == == <>
<> Albuquerque, NM USA | |||| |||| <>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
