Linux-Development-Sys Digest #175, Volume #8 Tue, 26 Sep 00 21:13:14 EDT
Contents:
pipe function ("Richard Lim")
Re: pipe function (Barry Margolin)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Re: Linux Stack Sizes? (Joe Pfeiffer)
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Process priorities ("Frank Dijcks")
Re: Wait queues and a race condition on 2.2.x (Lee Cremeans)
Re: Wait queues and a race condition on 2.2.x (Lee Cremeans)
Re: Process priorities (Rick Ellis)
using Posix/SystemV semaphores under Linux RH 6.2 (Stephane Richard)
Re: executing userspace apps (Karl Heyes)
Re: Kernel space vs User space (Christopher Browne)
Re: Message distribution manager / server (Christopher Browne)
C++ in kernel space (Thomas Schwere)
Re: C++ in kernel space (Christopher Browne)
Re: C++ in kernel space (Kaz Kylheku)
----------------------------------------------------------------------------
From: "Richard Lim" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: pipe function
Date: Wed, 27 Sep 2000 00:36:23 +0800
I am currently developing a simple piping program for my assignment in
linux/unix.
eg. ls -l !pipe less
pipe 'left command' to 'right command'
just like the bash shell pipe eg. ls -1 | less
the problem I've encounter is that if ls -l or other 'left command' has to
pipe more then aprrox 512byte of data to the 'right command', the program
will fail. How can I solve this?
I really appreciate your advice, please help. Thank you.
regards,
richard lim
attached is my source code.
/* mypipe.c*/
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<sys/stat.h>
#include<sys/types.h>
#include<fcntl.h>
#include<signal.h>
#include<string.h>
#include<time.h>
#include<wait.h>
#include<sys/param.h>
void rdpipe(char* commStr);
int main(int args, char *argv[])
{
// char commStr[1024] = "ls -la !pipe less"; // it doesn't work
char commStr[1024] = "ls -a !pipe less"; // it work
rdpipe(commStr);
}
void rdpipe(char* commStr)
{
int status;
int pipeIO[2];
int n;
int pid1, pid2;
char* execStr1;
char* execStr2;
execStr2 = strstr(commStr, " !pipe ");
n = strlen(commStr)-strlen(execStr2);
execStr1 = (char*)calloc(n+1, sizeof(char));
strncpy(execStr1, commStr, n); // get execStr1 command
*(execStr1+n) = '\0';
execStr2+=strlen(" !pipe "); // get execStr2 command
pipe(pipeIO);
pid1 = fork();
if(pid1 == 0)
{
int count = 1;
char *buffer[32];
close(pipeIO[0]);
dup2(pipeIO[1], 1);
buffer[0] = strtok(execStr1, " ");
while(buffer[count++] = strtok(NULL, " "));
if(execvp(buffer[0], buffer) == -1)
{
write(2,"invaild command\n", 16);
exit(EXIT_FAILURE);
}
}
else
{
waitpid(pid1, &status, 0);
printf("pid1 status :%d", status);
dup2(1, pipeIO[1]);
pid2 = fork();
if(pid2 == 0)
{
int count = 1;
char *buffer[32];
close(pipeIO[1]);
dup2(pipeIO[0], 0);
buffer[0] = strtok(execStr2, " ");
while(buffer[count++] = strtok(NULL, " "));
if(execvp(buffer[0], buffer) == -1)
{
write(2,"invaild command\n", 16);
exit(EXIT_FAILURE);
}
}
else
{
waitpid(pid2, &status, 0);
dup2(0,pipeIO[0]);
}
}
}
------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: pipe function
Date: Tue, 26 Sep 2000 16:47:59 GMT
In article <8qqj4q$co1$[EMAIL PROTECTED]>,
Richard Lim <[EMAIL PROTECTED]> wrote:
>I am currently developing a simple piping program for my assignment in
>linux/unix.
>eg. ls -l !pipe less
>pipe 'left command' to 'right command'
>just like the bash shell pipe eg. ls -1 | less
>
>the problem I've encounter is that if ls -l or other 'left command' has to
>pipe more then aprrox 512byte of data to the 'right command', the program
>will fail. How can I solve this?
>I really appreciate your advice, please help. Thank you.
The problem is that you're waiting for the child process to exit before
exec'ing the second program. The pipe can only buffer 512 bytes of data.
When the writing process writes more than this, it has to wait for the
reading process to read some of it to make room. But since you haven't
started reading from the pipe, you're deadlocked.
--
Barry Margolin, [EMAIL PROTECTED]
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 17:04:53 GMT
On Tue, 26 Sep 2000 16:30:04 GMT, [EMAIL PROTECTED] (Pete Zaitcev)
wrote:
>>[...]
>> First, you are assuming that the stack lives in high memory and grows
>> towards low memory. You cannot assume that. There is absolutely no
>> reason the stack couldn't live in low memory, and grow upwards. Many
>> implementations of UNIX and other OSs do exactly this.
>
>"Many" meaning HP-UX, I assume. :)
>
>This is irrelevant because we are talking Linux/i386 here.
Yes, exactly.
>He may have just hacked that code up in couple of minutes.
About 10. :-) It was to validate the assumption that the stack
memory was there and available for use. Just a test program.
>> For example, you could use alloca(). [...]
>
>Good idea, I was just going to suggest that. Only instead, I think
>it may be better for the poor soul to look how alloca() is implemented
>in glibc.
Especially given that John reported alloca was busted. :-)
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 13:12:11 -0400
Reply-To: [EMAIL PROTECTED]
%% Johan Kullstam <[EMAIL PROTECTED]> writes:
jk> btw alloca has been broken for the latest versions of gcc (like
jk> 2.95.x). they may have fixed this, but it can't hurt to check.
Hmm. Can you give more details about exactly when it fails? It
certainly can't be failing for "normal" usage, since just about every
GNU program makes extensive use of alloca(), and if it were broken in
the 2.95.x series I'm sure many people would have heard about it, since
most Linux systems would be about useless.
If it is indeed broken, it must be in only certain, fairly pathological
cases.
jk> just allocate a vector using a variable rather than a constant and
jk> gcc will magically do the right thing.
This is what I called "variable size arrays", a new component of the
1999 ISO C standard (implemented before that in GCC, of course--but now
it's "official").
>> If you can't do that, and your compiler supports the 1999 ISO C
>> standard, you can use variable size arrays
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes?
Date: 26 Sep 2000 11:43:48 -0600
MeekGeek <[EMAIL PROTECTED]> writes:
>
> Did you look at the short program I posted? It's just a simple
> program that reads and writes stack locations until it runs out of
> stack. I don't reach 7K.
I got a response yesterday as to what was wrong. The way you were
probing for stack addresses was badly broken; if you use it as
intended, everything works.
Here's a little program that allocates the stack addresses it's
reading and writing, rather than just touching them and hoping they're
there. It allocates its 4M and runs just fine....
#include <stdlib.h>
int main() {
char *stckptr;
int i;
stckptr = alloca(4*1024*1024);
for (i = 0; i < 4*1024*1024; i++) {
if ((i % 1024)==0) printf("%d\n", i);
stckptr[i] = (i % 26) + 'A';
}
for (i = 0; i < 4*1024*1024; i++)
printf("%c\n", stckptr[i]);
return(0);
}
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 13:53:03 -0400
Reply-To: [EMAIL PROTECTED]
%% MeekGeek <[EMAIL PROTECTED]> writes:
m> C compilers do just that. They don't call alloca() on each function
m> call. Instead, they just push the arguments and use the stack memory.
Yes, certainly, but the compiler does many magic things that are very
difficult for "normal users" to do. At least, in a portable fashion.
The implementation of alloca() itself can be found both in the source
code to GCC and in the source code to GLIBC. That's probably as good a
place to start as any.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 13:57:47 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Pete Zaitcev) writes:
pz> This is irrelevant because we are talking Linux/i386 here.
His message said he was porting to Solaris and Linux, and there is
nothing in that message about restricting it to the i386 hardware.
Solaris runs on both i386 and SPARC, of course, and Linux runs on a
_lot_ of hardware besides Intel & clones.
Of course, I don't know how the stack works on these different
platforms, and I would certainly assume it works the same way regardless
of the hardware.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 14:28:42 -0400
Reply-To: [EMAIL PROTECTED]
%% MeekGeek <[EMAIL PROTECTED]> writes:
m> Especially given that John reported alloca was busted. :-)
It's not busted in general. You can't swing a dead shell command in
Linux without running a program that uses alloca() in some form, and
almost all recent distros have been compiled exclusively with one of the
GCC 2.95.x series compilers.
Example: GLIBC's globbing functions use alloca().
I searched the GCC bug database and the only bug reported against GCC
for alloca() is one that says using it directly within a function
invocation may not work.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=169&database=gcc
This is trivially avoided.
Certainly I've _never_ seen code such as that in Johan's example fail in
GCC 2.95.x.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Frank Dijcks" <[EMAIL PROTECTED]>
Subject: Process priorities
Date: Tue, 26 Sep 2000 10:42:05 +0200
I have written a deamon on Linux that is polling an input port at 10 msec to
monitor an alternating signal. The program itself is working fine, but I do
have a small problem.
When other processes are running concurrently (and loading the CPU), my
deamon does not get enough CPU time to do its polling at fixed 10 msec
intervals.
Is there a way to increase the process priority of my program?
Or better: a way to guarantee some code in my program is executed at fixed
intervals of 5 to 20 msec??
Frank
[EMAIL PROTECTED]
------------------------------
From: Lee Cremeans <[EMAIL PROTECTED]>
Subject: Re: Wait queues and a race condition on 2.2.x
Date: Tue, 26 Sep 2000 16:09:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Pete Zaitcev) wrote:
> > .
> > .
> > /* send a encrypt/decrypt request to the other part of the driver
here
> > */
> > save_flags(flags);
> > cli();
> > interruptible_sleep_on_timeout(&waitq, HZ) /* 1 second timeout */
> > restore_flags(flags);
> > if(timeout == 0) {
> > /* We timed out. Abort the request */
> > /* cleanup stuff goes here */
> > return -EIO;
> > }
> > .
> > .
>
> What is ``timeout''? I guess it races right there.
>
> BTW, sleep_on is quite tricky to get right,
> you would be safer using schedule(), add_to_wait_queue(),
> remove_from_wait_queue().
I looked at some of my sample code, and I'm not quite sure how to do
this in a situation where another subroutine needs to pick up where
this one slept. All of the code I've seen just has it waiting on some
event, then continuing in the same subroutine. I guess what I'm asking
is how to signal a wakeup in another palce in the code. Can this be
done?
-lee
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Lee Cremeans <[EMAIL PROTECTED]>
Subject: Re: Wait queues and a race condition on 2.2.x
Date: Tue, 26 Sep 2000 16:09:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Pete Zaitcev) wrote:
> > .
> > .
> > /* send a encrypt/decrypt request to the other part of the driver
here
> > */
> > save_flags(flags);
> > cli();
> > interruptible_sleep_on_timeout(&waitq, HZ) /* 1 second timeout */
> > restore_flags(flags);
> > if(timeout == 0) {
> > /* We timed out. Abort the request */
> > /* cleanup stuff goes here */
> > return -EIO;
> > }
> > .
> > .
>
> What is ``timeout''? I guess it races right there.
>
> BTW, sleep_on is quite tricky to get right,
> you would be safer using schedule(), add_to_wait_queue(),
> remove_from_wait_queue().
I looked at some of my sample code, and I'm not quite sure how to do
this in a situation where another subroutine needs to pick up where
this one slept. All of the code I've seen just has it waiting on some
event, then continuing in the same subroutine. I guess what I'm asking
is how to signal a wakeup in another palce in the code. Can this be
done?
-lee
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Process priorities
Date: 26 Sep 2000 19:19:53 GMT
In article <8qqpvm$g89$[EMAIL PROTECTED]>,
Frank Dijcks <[EMAIL PROTECTED]> wrote:
>I have written a deamon on Linux that is polling an input port at 10 msec to
>monitor an alternating signal. The program itself is working fine, but I do
>have a small problem.
>When other processes are running concurrently (and loading the CPU), my
>deamon does not get enough CPU time to do its polling at fixed 10 msec
>intervals.
>
>Is there a way to increase the process priority of my program?
>Or better: a way to guarantee some code in my program is executed at fixed
>intervals of 5 to 20 msec??
You really should do this in a driver. That way you could get the timer
tic and do the polling then.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Stephane Richard <[EMAIL PROTECTED]>
Subject: using Posix/SystemV semaphores under Linux RH 6.2
Date: Tue, 26 Sep 2000 19:54:52 GMT
Reply-To: [EMAIL PROTECTED]
I want to use semaphores with process sharing under Linux RH 6.2.
I'm currently using sem_init() as a POSIX semaphore under a Linux
system and with a parameter to decide to use process sharing or not.
It seems that I have some problems with it anyway. I don't know why.
This call (sem_init) is described as a POSIX semaphore. Should I use
the SystemV semaphores (semctl, semop) ?
Does somebody know if something changed between RH6.1 (2.2.5) and RH 6.2
(2.2.14) because my program was working fine with 6.1
Thanks for your help/time.
Stef.
--
_________________________________________________
Stephane Richard
Kasenna Inc. Redefining Broadband Video!
(650) 943 8702 [EMAIL PROTECTED]
--
_________________________________________________
Stephane Richard
Kasenna Inc. Redefining Broadband Video!
(650) 943 8702 [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: executing userspace apps
Date: Wed, 27 Sep 2000 00:40:55 +0000
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Hi,
>
> I was wondering if it is possible to execute a userspace application
> from within the kernel (particularly binfmt_elf.c)... something along the
> lines of execl()...
>
look at kmod or init in the kernel for this. it firsts does a clone then exec
modprobe
karl.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Kernel space vs User space
Reply-To: [EMAIL PROTECTED]
Date: Wed, 27 Sep 2000 00:21:12 GMT
In our last episode (Sat, 23 Sep 2000 04:46:26 GMT),
the artist formerly known as Christopher Browne said:
>In our last episode (Fri, 22 Sep 2000 22:10:22 +0000),
>the artist formerly known as Karl Heyes said:
>>In article <8qegmb$1pp$[EMAIL PROTECTED]>, "Nera"
>><[EMAIL PROTECTED]> wrote:
>>> Can me get more resource when running the code in kernel space
>>> other = than user space?
>>
>>resource? CPU, memory, disk ? generally no.
>
>Well, _in theory_, kernel mode gives the ability to get direct access
>to _anything_ on the whole system before user mode gets access to it.
>
>But if you expect user mode to actually _work_, and if you want to
>"play by the rules," it is vastly _less_ convenient to "play well" and
>use great amounts of resources in kernel mode.
>
>A "for instance" being that in the kernel, the _proper_ way to
>allocate memory involves using kmalloc() rather than malloc(), where
>kmalloc() has considerably more restrictions in order that the kernel
>behave well.
As "more-than-an-FYI," the other BIG problem is that when you're
writing code inside the kernel, you DON'T have all of LIBC to play
with.
For instance, malloc() [suggested above] is part of LIBC, and is not
available due to the unavailability of LIBC. Ditto for all sorts of
other services you would expect to have in user mode.
The major _point_ of the kernel is to provide the services that will
then be "published" to users via LIBC; it is the "bootstrap," which
means that you can't safely use LIBC-like services while in the
kernel.
Pushing things into the kernel to somehow improve responsiveness or
robustness _CAN_ be feasible and useful, it's just that it has to be
carefully planned, and it is extremely naive to assume that it is
necessarily better to push things into the kernel. [The converse,
that _nothing_ must _ever_ get added to the kernel, is also naive, but
not necessarily so badly...]
--
(concatenate 'string "aa454" "@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lsf.html>
BIOS = Bugs Inherited from Older Systems
-- [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux,comp.os.linux.development.apps
Subject: Re: Message distribution manager / server
Reply-To: [EMAIL PROTECTED]
Date: Wed, 27 Sep 2000 00:21:17 GMT
In our last episode (26 Sep 2000 00:30:50 -0400),
the artist formerly known as Alexander Viro said:
>In article <66Vz5.48823$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>>In our last episode (Thu, 14 Sep 2000 17:05:22 -0600),
>>the artist formerly known as Dave Vance said:
>>>Can anybody tell me if there is such a thing as an Event Distribution
>>>Manager / Event Notification Server / Message Queue Manager / Message
>>>Distribution Manager / Message Notification Server.. for Linux?
>>>
>>>Basically, an entity (application, driver, whatever) that accepts messages
>>>from one set of applications and forwards those messages on to another set
>>>of applications, which have "registered" with the distribution manager to
>>>receive messages.
>>
>>Several options are out there; see sundry URLs below for links to such
>>alternatives as:
>>a) SystemV message queues (a kernel-level MQ scheme)
>>b) Isect - multiplatform MOM package available under GPL and LGPL
>>c) http://OpenQueue.sourceforge.net - Java-based MQ system
>>d) Falcon MQ - Commercial package that interoperates with MSMQ
>>e) IBM MQSeries <http://www.hursley.ibm.com/mqseries/mq>
>
>Ouch. If you are game for real fun - let's port plumber.
Interesting... I hadn't seen it before...
Making it reasonably secure, and usable by many users simultaneously,
probably mandates having namespaces. (e.g. - MY /mnt/plumb/send
should be distinct from YOUR /mnt/plumb/send, and when I connect
/mnt/plumb/edit to gnuclient, that is distinct from YOU connecting it
to vi, or perhaps sam...) Is that happening in the near future?
[Aside: Grumble, grumble, the other systems I suggested largely queue
information to disk so that if there is an outage, they should be able
to pick up where they left off, whereas the Plan 9 scheme seems
oriented towards "lighter weight" interactive tasks like passing
compiler errors out to indicate where a text editor should jump to...
Conceptually, they're similar, but I'd probably rather use MQSeries to
build an accounting system...]
--
(concatenate 'string "cbbrowne" "@" "hex.net")
<http://www.hex.net/~cbbrowne/linux.html>
"... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
------------------------------
Date: Tue, 26 Sep 2000 14:52:34 +0200
From: Thomas Schwere <[EMAIL PROTECTED]>
Subject: C++ in kernel space
Hi there,
I have to build a module which consists of some c-files and some
c++-files. Is there any possibility to compile/link the c++-files for
the kernel space?
Thanks a lot
--
//\\\\
| ~ ~ |
( O O )
___________________________________oOOo______( )_____oOOo_______
Thomas Schwere Phone: +41 1 445 16 61
Supercomputing Systems AG Fax: +41 1 445 16 10
Technoparkstrasse 1 Url: www.scs.ch
CH-8005 Zurich Email: [EMAIL PROTECTED]
Switzerland
Oooo
_________________________________________oooO______( )_________
( ) ) /
\ ( (_/
\_)
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: C++ in kernel space
Reply-To: [EMAIL PROTECTED]
Date: Wed, 27 Sep 2000 00:50:02 GMT
In our last episode (Tue, 26 Sep 2000 14:52:34 +0200),
the artist formerly known as Thomas Schwere said:
>I have to build a module which consists of some c-files and some
>c++-files. Is there any possibility to compile/link the c++-files for
>the kernel space?
Only if you can make sure that they make NO reference to any services
that require access to the standard C++ library, much as C code in
the kernel cannot make reference to services that require LIBC.
In practice, this seems to prove prohibitive to the practice...
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/linux.html>
"I found out that when you get married the man becomes the head of the
house. And the woman becomes the neck, and she turns the head any way
she wants to." - Yakov Smirnoff
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: C++ in kernel space
Reply-To: [EMAIL PROTECTED]
Date: Wed, 27 Sep 2000 00:50:12 GMT
On Tue, 26 Sep 2000 14:52:34 +0200, Thomas Schwere <[EMAIL PROTECTED]> wrote:
>Hi there,
>
>I have to build a module which consists of some c-files and some
>c++-files. Is there any possibility to compile/link the c++-files for
>the kernel space?
Yes, but there are some problems. Firstly, the kernel headers make fairly
liberal use of C++ keywords. My suggestion is this: create a C++ header which
creates a macro that renames every single C++ keyword to something else, e.g.
#define namespace cpp_nonkeyword_namespace
Then create a header which #undef's each one of these macros.
Then at the top of your source files, include the first header, then any
kernel headers, and then the header with the #undef's.
Also, don't forget the extern "C" { ... } around the kernel headers, e.g.
#include "rename_keywords.h"
extern "C" {
include <linux/sched.h>
/*... etc ...*/
}
#include "unrename_keywords.h"
Secondly, you may find that the code generated for constructors may have an
unresolved reference to __builtin_new. The workaround is to define your own
file scope operators new and delete (might as well make them call kmalloc and
actually use them).
Writing kernel code in C++ is not something that a lot of people do, so don't
expect a lot of support!
------------------------------
** 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
******************************
