- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "Linux Kernel Developer" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 30, 2000 8:04 AM
Subject: Re: Need info on the use of certain datastructures and the first
C++
> > files in the kernel will all be happy in Linuxland. Can any external
>
> Why do you need to touch any existing kernel .c source file ? If you make
> that patch, this breaks "situation 1" above.
It doesn't break situation 1 as the minor changes I've made to those 2 C
files should not have
On Mon, 30 Oct 2000 18:16:44 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> 2.4 symbol generation code never sees the C++ names, 2.5 code might.
>> To detect a mismatch between kernel headers and the module version
>> file, I have to generate the checksum for the consumer of the symbol
>> (C
> 2.4 symbol generation code never sees the C++ names, 2.5 code might.
> To detect a mismatch between kernel headers and the module version
> file, I have to generate the checksum for the consumer of the symbol
> (C++) as well as the generator of the symbol (C) and compare them.
These are structu
On Mon, 30 Oct 2000 14:02:38 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> As part of the 2.5 kbuild redesign, symbol versions will be completely
>> redone. One of the things on my todo list is to detect this mismatch.
>> There are some problems in doing that which I may or may not be able
> As part of the 2.5 kbuild redesign, symbol versions will be completely
> redone. One of the things on my todo list is to detect this mismatch.
> There are some problems in doing that which I may or may not be able to
> overcome, but if the field names are different between C and C++ then I
> ca
On Mon, 30 Oct 2000 13:41:40 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>> >You may find that creating your own wrappers for these files that do
>> >
>> >extern "C" {
>> >#define new new_
>> >#define private private_
>> >#include
>> >#undef new
>> >#undef private
>> >}
>
> >You may find that creating your own wrappers for these files that do
> >
> >extern "C" {
> >#define new new_
> >#define private private_
> >#include
> >#undef new
> >#undef private
> >}
> >
> >safer, since you won't break anything
>
> It breaks module symbol versions, see earlier mail to l-k.
On Mon, 30 Oct 2000 13:04:06 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>You may find that creating your own wrappers for these files that do
>
>extern "C" {
>#define new new_
>#define private private_
>#include
>#undef new
>#undef private
>}
>
>safer, since you won't break anything
It br
> js_dev::new. My questions are basically this. If I update these data
> structure members' names along with the references to them in various C
> files in the kernel will all be happy in Linuxland. Can any external
That may well be a problem. Also the use of private.
> utilities be broken or
On Mon, 30 Oct 2000 13:00:06 +0100,
"J . A . Magallon" <[EMAIL PROTECTED]> wrote:
>And what about struct fields ? It is the same. If you change the name of a field
>permanently, you have to modify the C source that uses it. But names are not
>important for binary compatability, so you can make th
On Mon, 30 Oct 2000 12:09:49 Linux Kernel Developer wrote:
> The goal of this project is to clean up the kernel headers so as they are
> useable/compatible with those who wish to program their kernel modules in
> C++. It is not my goal to rewrite the kernel in C++ or anything like that,
Fist of
Hi all,
After a delay on some other project I've again started up the process of
fixing up the Linux headers, i.e. removing the use of C++ keywords as
variable and stuff. I have questions on the use of three datastructures
which happen to use the C++ keyword new but first a couple of things.
13 matches
Mail list logo
