Re: gcc-2.95.2-51 is buggy
> > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs > > gcc version 2.95.2 19991024 (release) > > % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug > > 0x8480 > > % /usr/gcc/aeb/bin/gcc -v > > Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs > > gcc version 2.95.2 19991024 (release) > > % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug > > 0x0 > > > > So, not all versions of gcc 2.95.2 are equal. > > Interesting. Plain vanilla 2.95.2 from ftp.gnu.org exhibits the same > bug on an BSDI2.1 i386 system. > > defiant ~/tmp$ gcc -v > Reading specs from /usr/local/gnu/lib/gcc-lib/i386-pc-bsdi2.1/2.95.2/specs > gcc version 2.95.2 19991024 (release) > defiant ~/tmp$ gcc -O2 -o bug bug.c; ./bug > 0x480 > > Ion > Don't know if anyone else has noticed this but from what I've seen posted it appears, unless I missed something, the gcc 2.95.2s that have exibited the bug were compiled for a 386 or a 486 while the one on which it worked was a 686. Perhaps the bug only appears on certain gcc configurations. Either the build configuration or the default optimization method(s), if I remember correctly gcc optimizes for the platform (i.e. i386, i486, i586, etc) it was configured for by default. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Phantom PS/2 mouse persists..
- Original Message - From: "Steven N. Hirsch" <[EMAIL PROTECTED]> To: "Jeff V. Merkey" <[EMAIL PROTECTED]> Cc: "Alan Cox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, December 03, 2000 5:42 PM Subject: Re: Phantom PS/2 mouse persists.. > On Sun, 3 Dec 2000, Jeff V. Merkey wrote: > > > > On Sun, Dec 03, 2000 at 06:27:52PM +, Alan Cox wrote: > > > > > > > > I've fixed the major case. I can see no definitive answer to the other ghost > > > > PS/2 stuff (except maybe USB interactions). I take it like the others 2.4test > > > > also misreports a PS/2 mouse being present. > > > > > > > > Anyway I think its no longer a showstopper for 2.2.18. Someone with an affected > > > > board can piece together the picture > > > I just tested 2.2.18-24 as a boot kernel with anaconda -- works great -- > > mouse problem on PS/2 system is nailed. > > I always seem to own the wierd hardware. I agree the mouse > mis-detection isn't a showstopper - just damn annoying. > > FWIW, USB isn't compiled into the kernel in question. > Definately could be your hardware. I once saw a 486 board (PcChips M571 I think) which would report a PS/2 mouse even though the port didn't even exist on the motherboard. This problem showed up on all versions of Win9x. >From what I could tell it appeared as if the BIOS had support for the PS/2 mouse port but the port pins themself had not been saudered onto the board and for some reason the board alway thaught it had a PS/2 mouse and reported as so to Windows. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
Wasn't the original complaint that the kernel headers use C++ keyword and thus prevent the writing of, at least some, modules in C++. I have written C++ code before that was as least as fast as comparable C code and more efficient in some ways. Whether this could be or not be reproduced in kernel code I do not know. So far I have done my kernel programming in C. However even if I or other programmers would like to give this a try it is my understanding we cannot because of the header situation. I think it is unfair to attack C++ kernel code that is unable to come into existence, at least without jumping through a bunch of hoops, due to external influences (i.e. the incompatible headers). On a separate note. Isn't one of the philosophies behind Linux the idea of freedom. If people wish to try and program their modules in C++ for whatever reason, be it porting from existing code or to object orient their code, should they be free to do so. If the header situation is true, which I am not sure of since I have not tried to do C++ programming in kernel code, then people aren't free to write modules however they wished. Seeing as fixing the headers should be rather trivial and probably is the right thing to do anyway (using existing language keywords is a bad idea) I do not see why this same flame war must erupt every time the header situation is brought up. Its not as if C++ code would all of the sudden popup in the kernel core forcing everybody to use C++. At best a driver here and there might start using it and its continual usage would depend on if its implementation is successful or not. And those drivers themselves are extremely likely to be self-contained thus not affecting anybody else's kernel code. > If C++ really is that good for kernel modules, I'd like to > see some code that proves it can be done without too much > of a performance hit (or without a performance hit at all?). > > Sending 500 rants to the kernel list isn't even close to > being productive. Sending 1 patch is... > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Possible C++ safe header project - Re: [Criticism] On the discussion about C++ modules
OK I've decided to give this a shot, IF there is sufficient interest out
there for C++ safe headers. So all you coders out there who have tried and
failed or who wish to program kernel modules in C++ join in and help out by
listing the errors you have encountered with the current header setup.
This is currently what I plan to do to make safe headers.
1. Insert
#ifdef __cplusplus
extern "C" {
#endif
at the begining of each header file and
#ifdef __cplusplus
}
#endif
at the end of each header file.
2. In the files which contain the usable of C++ keywords I intend to use
define statements such as the one below for the offending keywords:
#ifdef __cplusplus
#define class lk_class
#defined new lk_new
..
#endif
A side effect of this is that certain kernel variables make have to be
accessed in a C++ module with a new lk_ prefix. However C code will not be
affected. I don't like the idea of using the define statements especially
after seeing the horror Palm did in their SDK however I cannot think of
another way to transparently fix this unless the offending header code is
self contained. If anyone has a better idea let me know.
3. Add a new header for C++ modules that currently only include definitions
for the new and delete operator functions. This should be simple enougth.
Basically map new to kmalloc and delete to kfree. new will be a
non-exception version that returns NULL on error just like it used to do
before the horrible new C++ standard. I'm not even going to go near
exceptions as that IMHO creates non-clear and hard to debug execution paths
in code.
Please comment on the pluses and minuses of each planned task and on
other things that you may see that should be done. Please no flames unless
they contain useful information. Also I plan to implement the first patches
for 2.2.x. I prefer to work on a stable codebase at least while the project
gets off the ground. The other thing I'd like to know if the eventual
patch, if there is any as this is dependant on interest, would be considered
for inclusion into the standard source base.
Let the games begin.
> The "incompatible headers" can be cured mostly with just:
>
> extern "C" {
> #define new header_new
> #define ...
> #include
> #undef new
> #undef ...
> }
>
> If they can't go this far, or create a local patch for the offending
> headers (perhaps even suggesting it for inclusion) I don't see why they
> should even be considered, not to mention taken seriously...
>
> Fix it, send in a patch and get over it. Given your email address, this
> should be a no-brainer for you. At the very least, such a patch will
> (hopefully) stop this nonsense.
>
> > Its not as if C++ code would all of the sudden popup in the
> > kernel core forcing everybody to use C++. At best a driver here and
there
> > might start using it and its continual usage would depend on if its
> > implementation is successful or not. And those drivers themselves are
> > extremely likely to be self-contained thus not affecting anybody else's
> > kernel code.
>
> I'd prefer the kernel staying plain C, with no admixtures. Just MHO, of
> course. What somebody else does in the privacy of their own trees is their
> bussiness, as always.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Linux C++ safe header project
Hi all,
I'm looking through the suggestions and stuff that I have gotten so far.
As for the extern "C" stuff I'm torn between fixing the headers internally
or making side-by-side header files for C++ users. Such as:
a.h exists. So I create a a.hpp which contains somthing like the following:
a.hpp:
#ifndef __A_HPP__
#define __A_HPP__
#ifdef __cplusplus
extern "C" {
#endif
#include "a.h"
#ifdef __cplusplus
}
#endif
#endif
I'm not crazy about the second approach but open to it if the other one is
considered too intrusionary, a statement which I question considering the
$ifdef's leave the headers unchanged for C code.
As a first step in the project I've create a program that can be used to
update all the header files to include
#ifdef __cplusplus
extern "C" {
#endif
at the begining of each header file and
#ifdef __cplusplus
}
#endif
at the end of each header file. Said program is attached. Testers have
fun.
Note: this is only the first step to C++ safe header files. So please no
complaits about the C++ keywords. They still remain, for now.
- A. B.
begin 666 mkcppsaf.pl
M(R$O=7-R+V)I;B]P97)L"B,@4')O9W)A;2!N86UE.B!M:V-P<'-A9BYP; HC
M(%!R;V=R86UM960@:6XZ(%!E3H@
M02X@0BX*(R!0=7)P;W-E.B!4:&ES('!R;V=R86T@9FEX97,@0R!H96%D97(@
M9FEL97,@9F]R($,K*R!B>2!P;&%C:6YG(&%N(&5X=&5R;B B0R(*(R @(" @
M(" @("!W#H@;6MC<'!S868@6V1I
M"]I;F-L=61E+PH*
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,*"B,)"0E);F-L
M=61E(')E<75I&ET*&UA:6XH0$%21U8I*3L*"B,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C"@HC"0D)36%I;B!P2 D9&ER(#T@*&EN="A 05)'5BD@
M/B P*2 _("1!4D=66S!=(#H@(B]U7!E(&8@+7!R:6YT('PB*2DI"@E["@D)
M4U1$15)2+3YP&EN9SH@)7,N+BXB+" D9FYA;64I.PH*"0EI9BAU<&1A=&5?
M9FEL92@D9FYA;64I(#T](# I"@D)>PH)"0EP2 H)&9N86UE*2 ]($!?.PH);7D@)&1A=&$@/2 B(CL*"6UY("1F:6QE
M(#T@;F5W($9I;&5(86YD;&4["@H):68H(61E9FEN960H)&9I;&4M/F]P96XH
M)&9N86UE+"!/7U)$3TY,62DI*0H)>PH)"5-41$524BT^<')I;G1F*")5;F%B
M;&4@=&\@;W!E;B!F:6QE("5S.B E7-T96TH
Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
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.
First thing. Some had commented on my previous post that this did not
belong on the Linux kernel mailing list. I disagree with that assertion.
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,
merely to give those interested the option to program their modules in C++.
In order to accomplish this goal I may occasionally need to ask the various
kernel gods on this list whether changing a particular variable or structure
member name would cause a problem as I am also doing in this post. The
other reason I am posting, occasionally, on this list is to hopefully get
eyeballs and testers, from among those whom are most intimately familiar
with the kernel, to tryout my latest patch. And as a final note to some of
those whom responded negatively to my previous post I did not start the
previous flame war nor did I post a ton of messages. My previous posts on
the subject totaled 1 before I accepted someone's challenge to fix the
headers myself and since then I've only posted twice once to announce the
project and once with a script that would allow those interested to update
their header files with the 'extern "C" {}' compile conditional wrappers as
the starting point of the project. Any future posts will be limited to more
header fixes and/or questions on certain pieces of code I am looking to
modify. If and when I decide to start experimental kernel C++ projects such
as perhaps a generic virtual device driver classes that can be inheritable,
which by the way is not even near to my current goal, I will take those off
this list unless a question is required on the use of a particular data
structure or interface. And before the flames begin again I restate my
current goal is to fix the headers so they are useable in C++ and nothing
more.
Ok now the second thing I wish to announce in this post is that the
included C++ compatible header fixing patch fixes most references of the C++
keyword of "new" in the header files. The following files have been
updated. A couple of C files had to be updated as well due to parameters,
defined in the header files, being called "new". All of these were
straightforward fixes and should be correct, testing is welcome.
include/linux/arch/mips/kernel/irq.c
include/linux/include/asm-mips/irq.h
include/linux/include/asm-mips/mipsregs.h
include/linux/include/Linux/hdlcdrv.h
include/linux/include/Linux/list.h
include/linux/include/Linux/lists.h
include/linux/include/net/neighbour.h
include/linux/net/core/neighbour.c
Ok now on to the questions I have. In include/linux/joystick.h,
include/linux/raid5.h, and include/linux/adfs_fs.h I've found members of
structures and a union which were called "new". The datastructures in
question are union adfs_dirtail::new, struct stripe_head::new, struct
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
utilities be broken or anything like that. Or more precisely are there any
known external utilities that would be broken by this change? Thanks to all
those whom can give me a hand in this.
- A. B.
begin 666 c++-0.0.1.patch
M9&EF9B M"TR+C(N,3PH@"6EN="!S:&%R960@/2 P.PH@"7-T"]I;F-L=61E+V%S
M;2UM:7!S+VER<2YH"BTM+2!L:6YU>"TR+C(N,3"]I;F-L=61E+V%S;2UM:7!S+VER<2YH"4UO;B!/8W0@,S @,#$Z,C@Z,C<@
M,C P, I 0" M,3"]I;F-L=61E+V%S;2UM:7!S+VUI<'-R
M96=S+F@)36]N($]C=" S," P,3HR.#HR-R R,# P"D! ("TQ-C$L,3,@*S$V
M,2PQ,R! 0 H@("HO"B C9&5F:6YE(%]?0E5)3$1?4T547T-0,"AN86UE+')E
M9VES=&5R*2 @(" @(" @(" @(" @(" @(" @(" @(" @7 H@97AT97)N(%]?
M:6YL:6YE7U\@=6YS:6=N960@:6YT(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(%P*+7-E=%]C<#!?(R-N86UE*'5NR @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(%P*( EU;G-I9VYE
M9"!I;G0@"]I;F-L=61E+VQI;G5X+VAD;&-DPHK"6EF("AI"TR+C(N,3"TR+C(N,3"]L:7-T+F@)36]N($]C=" S," P,3HR
M.#HR-B R,# P"D! ("TS,"PR,B K,S L,C(@0$ *(" J(%1H:7,@:7,@;VYL
M>2!F;W(@:6YT97)N86P@;&ES="!M86YI<'5L871I;VX@=VAE'0["BT);F5W+3YP
M'0M/G!R978@
M/2!N97=?;F]D93L**PEN97=?;F]D92T^;F5X=" ](&YE>'0["BL);F5W7VYO
M9&4M/G!R978@/2!P'0@/2!N97=?;F]D93L*('T*
M( H@+RH*(" J($EN2!A9G1E'0I.PHK"5]?
M;&ES=%]A9&0H;F5W7VYO9&4L(&AE860L(&AE860M/FYE>'0I.PH@?0H@"B O
M*@ID:69F("UR("UU(&QI;G5X+3(N,BXQ-RYO"]L
M:7-T"]I;F-L=61E+VQI;G5X+VQI'0*
M("-D969I;F4@1$Q)4U1?4%)%5BAL:7-T;F%M*0EL:7-T;F%M+F1L7W!R978*
M( HM(V1E9FEN92!$3$E35%])3E-%4E1?049415(H;F]D92P@;F5W+"!L:7-T
M;F%M*0ED;R!["0E<"BT)*&YE=RDM/FQI'0M/FQI
M'0@/2 H;F5W*3L)"0E<"BLC9&
Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)
So which is the recommended compiler for each kernel version 2.2.x, 2.4.x(pre?) nowadays? I've pretty much kept gcc 2.7.2.3 around just for compiling the kernel however now I hear you need egcs to compile 2.4? I don't mind keeping 2.7.2.3 around in its own installation directory just for the purpose of doing kernel work however from a previous post I've now got the impression that egcs has become the recommended compiler? If I'm going to keep a secondary compiler around (outside of gcc 2.95.2 which I still hear is no good for kernel compiles) just for kernel work I'd prefer to use my disk space on the recommended one. > > [Rusty] > > > CC=gcc-2723 make 2.0 kernel > > > CC=gcc-2723 make 2.2 kernel > > > CC=egcs make 2.4 kernel > > > > No, environment doesn't override make variables by default. This > > works on any shell: > > > > make CC=egcs > > If you're going to get pedantic, that won't work either -- since the > makefiles in kernels 2.0 and 2.2 expect $(CC) to include some compiler > flags. This was fixed somewhere in 2.3.3x. > > Peter > - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
> > 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 changed any outputted code. The change was only in
the offending parameter names.
> AFAIK, ANSI C does not require that prototype (declaration) parameter
names and
> definition parameter names match, only types. So, this snippet is correct:
>
> int f(int onename);
>
> int f(int othername)
> {
> }
I think good style requires that the parameter names match in the
function prototype and its declaration. Besides which if I remember
correctly the latest C++ standard does require that the parameter names
match and the next C standard might follow suit. But I think that is a
minor issue, I only updated the C files (minimally at that) to keep
consistency.
> The "klass" example is directly taken from XFree header files, look at
> vi +239 /usr/X11R6/include/X11/Xlib.h
> vi +898 /usr/X11R6/include/X11/Xlib.h
>
> So the core X internals, written in C, use the "class" field, but anyone
using
> X in C++ programs has to use the field as "klass" or "c_class".
I bought up a solution like this before and it was mostly argued
against.
>
> I think X is a good example to provide C++ friendlyness with the minimal
> internal
> change. Perhaps this is a way to make kernel programmers-mantainers to
accept
> the
> headers patch, they can continue working the same...
The kernel gods will have to give their opinion on this. Should a
"proper" fix be implemented for the offending variable names or should a
workaround be implemented. Or perhaps a combination depending on whether
the change breaks any external utilities and how bad a break that is (I say
external utilities as I can update all the files in the kernel itself). I
am inclined to think that the proper fix should be done unless something
important break in which case the ugly workaround can be used in those
limited cases. However my mind is open to be changed. After all the ugly
workaround would actually be easier for me, one Perl script.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17
- 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++ keyword patch for 2.2.17
> > 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.
>
> 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
That was one of the two possible solutions I was looking at initially.
Having for example a module.hpp header file alongside module.h which did the
extern "C" {} wrapper along with the #define new lk_new, etc. Actually that
would be an easier task for me as I could easily write a Perl script which
automatically built that for any kernel. However from the responses I
gathered at the time it was mostly recommended against. I am also leary at
that option as some variable (and function?) names would differ when used in
either a C or C++ program and also after having seeing the horror Palm did
with defines in their SDK.
Perhaps this is what I should do. Continue making the straitforward
fixes that will not break anything and incorporate that into my main patch.
Fixes for situations such as the one I encountered in those 3 data
structures I will put into a separate patch for testing to see if the change
affects anybody. If those modifications happen prove unwise then for those
rare cases do the .hpp option on those header files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Question on HighPoint HPT370 support
Hi, I was wondering if support for the HPT370 RAID capabilities is planned? I found that with the IDE patch from Hedrick I was able to get regular EIDE device support for this controller however I was hoping to use its RAID capabilities. Is work on this being done? Thanks for any help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why no HPT370 RAID Support?
Hi, I was just wondering if there was some reason why the HPT370's RAID capabilities weren't supported in the enhanced IDE patch for 2.2.*? Or if support for its RAID capabilities were being worked on. I noticed FreeBSD also appears to fail to support its RAID features so I am partially inclined into thinking that its RAID capabilities are done in software and thats why its RAID support hasn't been added. However from reading its specs on its web page it appears to be a hardware solution. Is it just a lack of documentation? Or will its RAID capabilities be added to Linux? Thanks for your help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> No, actually the instability starts right after/when the root > filesystem is mounted (it seems). I have no foreign modules installed > when this error occurs. Even if I did, why would the Abit KA7 with the > same [other] hardware and software NOT show this problem, even with all > opts enabled? In my experience I've noticed motherboards can have a huge impact on stability despite the chipsets, hardware used, etc. Abit is well known and liked in the overclocking circles, consequently I would strongly suspect that their motherboards are generally highly stable when compared to most others. In fact, my experience with them seams to support this thesis. Its possible that the other motherboard you were using is just flaky. Does the other one happen to be a PC-Chips one? These generally can be quite cheap, feature rich, and even have the best chipsets but still have proved themselves to be quite flaky to me in the past. FIC seams to have a similar problem, although they actually improve on their boards stability over time (have some rock solid high volume servers on "stabilized" FIC boards); sometimes with just a conveniently available BIOS update. Shuttle also seams to have gone downhill but that might have just been a one time occurrence. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
