* Compiling C++ kernel module + Makefile @ 2004-01-16 21:09 Ashish sddf 2004-01-16 22:07 ` Richard B. Johnson 2004-01-16 22:40 ` Sam Ravnborg 0 siblings, 2 replies; 25+ messages in thread From: Ashish sddf @ 2004-01-16 21:09 UTC (permalink / raw) To: linux-kernel Hi, I am trying to port a C++ kernel module from 2.4 to 2.6. (It is MIT Click Modular Router). As I understand the module building has changed in ver 2.6. I have got the Makefile to compile it but it gives me lot of warning - all dependancies problem It appears that the kernel Makefile treats it like a host application and does not pass the necessary processing routines. Does anyone can ideas about how to change the kernel makefile to compile the C++ files the same way as C files ? Any help will be appreciated. Ashish __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-16 21:09 Compiling C++ kernel module + Makefile Ashish sddf @ 2004-01-16 22:07 ` Richard B. Johnson 2004-01-17 12:59 ` Bart Samwel 2004-01-16 22:40 ` Sam Ravnborg 1 sibling, 1 reply; 25+ messages in thread From: Richard B. Johnson @ 2004-01-16 22:07 UTC (permalink / raw) To: Ashish sddf; +Cc: linux-kernel On Fri, 16 Jan 2004, Ashish sddf wrote: > Hi, > I am trying to port a C++ kernel module from 2.4 to > 2.6. (It is MIT Click Modular Router). > > As I understand the module building has changed in > ver 2.6. I have got the Makefile to compile it but it > gives me lot of warning - all dependancies problem > > It appears that the kernel Makefile treats it like a > host application and does not pass the necessary > processing routines. > > Does anyone can ideas about how to change the kernel > makefile to compile the C++ files the same way as C > files ? > > Any help will be appreciated. > > Ashish If somebody actually got a module, written in C++, to compile and work on linux-2.4.nn, as you state, it works only by fiat, i.e., was declared to work. There is no C++ runtime support in the kernel for C++. Are you sure this is a module and not an application? Many network processes (daemons) are applications and they don't require any knowledge of kernel internals except what's provided by the normal C/C++ include-files. Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-16 22:07 ` Richard B. Johnson @ 2004-01-17 12:59 ` Bart Samwel 2004-01-19 13:46 ` Richard B. Johnson 0 siblings, 1 reply; 25+ messages in thread From: Bart Samwel @ 2004-01-17 12:59 UTC (permalink / raw) To: root, Ashish sddf; +Cc: linux-kernel On Friday 16 January 2004 23:07, Richard B. Johnson wrote: > If somebody actually got a module, written in C++, to compile and > work on linux-2.4.nn, as you state, it works only by fiat, i.e., was > declared to work. There is no C++ runtime support in the kernel for > C++. Are you sure this is a module and not an application? Many > network processes (daemons) are applications and they don't require > any knowledge of kernel internals except what's provided by the > normal C/C++ include-files. Rest assured, ;) this is definitely a module. It includes a kernel patch that makes it possible to include a lot of the kernel headers into C++, stuff like changing asm :: to asm : : (note the space, :: is an operator in C++) and renaming "struct namespace" to something containing less C++ keywords. The module also includes rudimentary C++ runtime support code, so that the C++ code will run inside the kernel. I'm afraid that the task of compiling it for 2.6 is going to be pretty tough -- the kernel needs loads of patches to make it work within a C++ extern "C" clause, and it probably completely different patches from those needed by 2.4. Getting the build system to work is the least of the concerns. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-17 12:59 ` Bart Samwel @ 2004-01-19 13:46 ` Richard B. Johnson 2004-01-19 17:40 ` Bart Samwel 0 siblings, 1 reply; 25+ messages in thread From: Richard B. Johnson @ 2004-01-19 13:46 UTC (permalink / raw) To: Bart Samwel; +Cc: Ashish sddf, linux-kernel On Sat, 17 Jan 2004, Bart Samwel wrote: > On Friday 16 January 2004 23:07, Richard B. Johnson wrote: > > If somebody actually got a module, written in C++, to compile and > > work on linux-2.4.nn, as you state, it works only by fiat, i.e., was > > declared to work. There is no C++ runtime support in the kernel for > > C++. Are you sure this is a module and not an application? Many > > network processes (daemons) are applications and they don't require > > any knowledge of kernel internals except what's provided by the > > normal C/C++ include-files. > > Rest assured, ;) this is definitely a module. It includes a kernel patch that > makes it possible to include a lot of the kernel headers into C++, stuff like > changing asm :: to asm : : (note the space, :: is an operator in C++) and > renaming "struct namespace" to something containing less C++ keywords. The > module also includes rudimentary C++ runtime support code, so that the C++ > code will run inside the kernel. I'm afraid that the task of compiling it for > 2.6 is going to be pretty tough -- the kernel needs loads of patches to make > it work within a C++ extern "C" clause, and it probably completely different > patches from those needed by 2.4. Getting the build system to work is the > least of the concerns. > > -- Bart > I can't imagine why anybody would even attempt to write a kernel module in C++. Next thing it'll be Visual BASIC, then Java. The kernel is written in C and assembly. The tools are provided. It can only be arrogance because this whole C v.s. C++ thing was hashed-over many times. Somebody apparently wrote something to "prove" that it can be done. I'd suggest that you spend some time converting it to C if you need that "module". The conversion will surely take less time than going through the kernel headers looking for "::". Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 13:46 ` Richard B. Johnson @ 2004-01-19 17:40 ` Bart Samwel 2004-01-19 18:39 ` Richard B. Johnson 2004-01-20 5:29 ` Valdis.Kletnieks 0 siblings, 2 replies; 25+ messages in thread From: Bart Samwel @ 2004-01-19 17:40 UTC (permalink / raw) To: root; +Cc: Ashish sddf, linux-kernel Richard B. Johnson wrote: >>>If somebody actually got a module, written in C++, to compile and >>>work on linux-2.4.nn, as you state, it works only by fiat, i.e., was >>>declared to work. There is no C++ runtime support in the kernel for >>>C++. Are you sure this is a module and not an application? Many >>>network processes (daemons) are applications and they don't require >>>any knowledge of kernel internals except what's provided by the >>>normal C/C++ include-files. >> >>Rest assured, ;) this is definitely a module. It includes a kernel patch that >>makes it possible to include a lot of the kernel headers into C++, stuff like >>changing asm :: to asm : : (note the space, :: is an operator in C++) and >>renaming "struct namespace" to something containing less C++ keywords. The >>module also includes rudimentary C++ runtime support code, so that the C++ >>code will run inside the kernel. I'm afraid that the task of compiling it for >>2.6 is going to be pretty tough -- the kernel needs loads of patches to make >>it work within a C++ extern "C" clause, and it probably completely different >>patches from those needed by 2.4. Getting the build system to work is the >>least of the concerns. > > I can't imagine why anybody would even attempt to write a kernel > module in C++. Next thing it'll be Visual BASIC, then Java. The > kernel is written in C and assembly. The tools are provided. It > can only be arrogance because this whole C v.s. C++ thing was > hashed-over many times. Somebody apparently wrote something to > "prove" that it can be done. I'd suggest that you spend some > time converting it to C if you need that "module". The conversion > will surely take less time than going through the kernel headers > looking for "::". Just to make this clear: I'm not the original poster, so I'm not the one who is to be helped. I just happened to know the module, and I'd thought I'd give you a quick answer because I knew it. :) Now, let me try to add a bit of nuance to your suggested solution. Try porting 100s of C++ files (yes, it's that large) making heavy use of inheritance etc. to C. Then try to make a bit of C code usable as extern "C" in C++. Extern "C" was actually meant to be able to grok most C code, while C++ wasn't meant to be easily portable to C. So, for any moderately large module that uses any C++ features at all, it's probably easier to make small syntactic changes to the kernel than to port the module to C (which would amount to a full rewrite). I'll give you a bit of background about the specific situation. I'm not involved with the project, so I don't know all the details, but I do know the code and have worked on a "competing" system (as far as research systems compete). The choice for C++ for this project is really the most obvious choice, as the model is very OO. The module implements a router model that is configured as "clickable modules", i.e., very small elements with input and output ports and a bit of state that are connected to each other through small interfaces. Their element implementations are arranged hierarchically (as in C++ class hierarchies). I'm not familiar with the exact history of the project, but I expect that they decided to do C++ because the model they try to express is best modeled using C++. This design decision can be debated, because it is perfectly feasible (albeit with a lot more work) to implement an OO model in C. In fact, I have helped to implement a similar framework (the OKE CORRAL) which was written completely in C. But, the fact of the matter is, this useful (but huge) kernel module is there now (and it has been here since the early 2.2 kernels), and it was not written just to "prove" that it could be done, but because C++ seemed at the time to be the best language for the job. The start of this project may very well predate the many times that this was hashed-over on the LKML (disclaimer: I wasn't there, so I don't know). You refer to "what can only be" the arrogance of the writers, yet continue by claiming: > I'd suggest that you spend some time converting it to C if you need > that "module". and > The conversion will surely take less time than going through the > kernel headers looking for "::". Excuse me, but before calling somebody else arrogant, I would suggest that you might want check whether you're not calling the kettle black. It's not a sign of modesty when you assume without a trace of doubt that a module (that happened to have been developed over the course of four years by a team of people at MIT) is just a "\"module\"" and that it will take less time to port it to C than to make the kernel headers parse in a C++ extern "C" clause. In addition, imagine how you would feel if somebody referred to your work as a "\"module\""! The fact that you "can't imagine why anybody would even attempt to write a kernel module in C++" may just as well be due to a lack of imagination on your side, but in your statement I detect no trace of a doubt. And _yes_ you may very well be right about their initial decision being stupid (and you might not be -- I don't know), and _yes_ you are probably right about the whole thing being hashed-over many times (I don't know -- I wasn't there), and _yes_ there are people out there who would do anything just to prove they can do something others think is impossible or just filthy. So, yes, there _may_ be a point to what you're saying. _May_. I'm not saying you're wrong, and I'm not saying you're right. What I'm saying is that simply assuming that any C++ module is nothing more than a few lines of (de)glorified C and accusing the writers of being arrogant just because they wrote a kernel module in C++ is, in my opinion, jumping to conclusions based on technical-preference-turned-prejudice (at least, that's how it seems), and it's not very polite either. Unfortunately, this is how flame wars get started (as can be seen by the slightly agitated tone this message has taken, sorry about that! :) ). Just to make this clear to everyone: I'm not trying to instigate a flame war here about C vs. C++, as I don't really have an opinion on that subject. This posting has to do with my preferences w.r.t. personal style, and nothing with my technical preferences. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 17:40 ` Bart Samwel @ 2004-01-19 18:39 ` Richard B. Johnson 2004-01-19 20:02 ` Bart Samwel 2004-01-20 5:29 ` Valdis.Kletnieks 1 sibling, 1 reply; 25+ messages in thread From: Richard B. Johnson @ 2004-01-19 18:39 UTC (permalink / raw) To: Bart Samwel; +Cc: Ashish sddf, Linux kernel On Mon, 19 Jan 2004, Bart Samwel wrote: > Richard B. Johnson wrote: > >>>If somebody actually got a module, written in C++, to compile and > >>>work on linux-2.4.nn, as you state, it works only by fiat, i.e., was > >>>declared to work. There is no C++ runtime support in the kernel for > >>>C++. Are you sure this is a module and not an application? Many > >>>network processes (daemons) are applications and they don't require > >>>any knowledge of kernel internals except what's provided by the > >>>normal C/C++ include-files. > >> > >>Rest assured, ;) this is definitely a module. It includes a kernel patch that > >>makes it possible to include a lot of the kernel headers into C++, stuff like > >>changing asm :: to asm : : (note the space, :: is an operator in C++) and > >>renaming "struct namespace" to something containing less C++ keywords. The > >>module also includes rudimentary C++ runtime support code, so that the C++ > >>code will run inside the kernel. I'm afraid that the task of compiling it for > >>2.6 is going to be pretty tough -- the kernel needs loads of patches to make > >>it work within a C++ extern "C" clause, and it probably completely different > >>patches from those needed by 2.4. Getting the build system to work is the > >>least of the concerns. > > > > I can't imagine why anybody would even attempt to write a kernel > > module in C++. Next thing it'll be Visual BASIC, then Java. The > > kernel is written in C and assembly. The tools are provided. It > > can only be arrogance because this whole C v.s. C++ thing was > > hashed-over many times. Somebody apparently wrote something to > > "prove" that it can be done. I'd suggest that you spend some > > time converting it to C if you need that "module". The conversion > > will surely take less time than going through the kernel headers > > looking for "::". > > Just to make this clear: I'm not the original poster, so I'm not the one > who is to be helped. I just happened to know the module, and I'd thought > I'd give you a quick answer because I knew it. :) > > Now, let me try to add a bit of nuance to your suggested solution. Try > porting 100s of C++ files (yes, it's that large) making heavy use of > inheritance etc. to C. Then try to make a bit of C code usable as extern > "C" in C++. Extern "C" was actually meant to be able to grok most C > code, while C++ wasn't meant to be easily portable to C. So, for any > moderately large module that uses any C++ features at all, it's probably > easier to make small syntactic changes to the kernel than to port the > module to C (which would amount to a full rewrite). > > I'll give you a bit of background about the specific situation. I'm not > involved with the project, so I don't know all the details, but I do > know the code and have worked on a "competing" system (as far as > research systems compete). The choice for C++ for this project is really > the most obvious choice, as the model is very OO. The module implements > a router model that is configured as "clickable modules", i.e., very > small elements with input and output ports and a bit of state that are > connected to each other through small interfaces. Their element > implementations are arranged hierarchically (as in C++ class hierarchies). > > I'm not familiar with the exact history of the project, but I expect > that they decided to do C++ because the model they try to express is > best modeled using C++. This design decision can be debated, because it > is perfectly feasible (albeit with a lot more work) to implement an OO > model in C. In fact, I have helped to implement a similar framework (the > OKE CORRAL) which was written completely in C. But, the fact of the > matter is, this useful (but huge) kernel module is there now (and it has > been here since the early 2.2 kernels), and it was not written just to > "prove" that it could be done, but because C++ seemed at the time to be > the best language for the job. The start of this project may very well > predate the many times that this was hashed-over on the LKML > (disclaimer: I wasn't there, so I don't know). You refer to "what can > only be" the arrogance of the writers, yet continue by claiming: > > > I'd suggest that you spend some time converting it to C if you need > > that "module". > > and > > > The conversion will surely take less time than going through the > > kernel headers looking for "::". > > Excuse me, but before calling somebody else arrogant, I would suggest > that you might want check whether you're not calling the kettle black. > It's not a sign of modesty when you assume without a trace of doubt that > a module (that happened to have been developed over the course of four > years by a team of people at MIT) is just a "\"module\"" and that it > will take less time to port it to C than to make the kernel headers > parse in a C++ extern "C" clause. In addition, imagine how you would > feel if somebody referred to your work as a "\"module\""! The fact that > you "can't imagine why anybody would even attempt to write a kernel > module in C++" may just as well be due to a lack of imagination on your > side, but in your statement I detect no trace of a doubt. And _yes_ you > may very well be right about their initial decision being stupid (and > you might not be -- I don't know), and _yes_ you are probably right > about the whole thing being hashed-over many times (I don't know -- I > wasn't there), and _yes_ there are people out there who would do > anything just to prove they can do something others think is impossible > or just filthy. So, yes, there _may_ be a point to what you're saying. > _May_. I'm not saying you're wrong, and I'm not saying you're right. > What I'm saying is that simply assuming that any C++ module is nothing > more than a few lines of (de)glorified C and accusing the writers of > being arrogant just because they wrote a kernel module in C++ is, in my > opinion, jumping to conclusions based on > technical-preference-turned-prejudice (at least, that's how it seems), > and it's not very polite either. > The possibility that something may have been written by some MIT people can't change the fact that C++ is not the tool that should have been used within the kernel. I once worked on a project at Princeton. That doesn't make me know anything about Relativity. Einstein didn't rub off due to some proximity effect. If the "MIT Team", as you so state, had actually inspected some kernel code, and actually understood what a Linux/Unix kernel does, then learned persons could not possibly have selected C++ for this project. If you review the project, you will probably also find that a large percentage of the code should have been implemented in user-mode (a daemon, or several). That's where C++ really shines. However, it wasn't. Which, to me, means that the developers were either clue-less or, once somebody actually figured out how a kernel works, it was way too late to change (an all to common problem). The number of persons who worked on a project does not affect the correctness of the tools nor the architecture chosen. Facts are not democratic. You can't vote them into or out of existence. > Unfortunately, this is how flame wars get started (as can be seen by the > slightly agitated tone this message has taken, sorry about that! :) ). > Just to make this clear to everyone: I'm not trying to instigate a flame > war here about C vs. C++, as I don't really have an opinion on that > subject. This posting has to do with my preferences w.r.t. personal > style, and nothing with my technical preferences. > This is not about preferences. Most software engineers wish that everything could be done using the first language they learned. Once they try to write a state-machine in FORTRAN (my native language), they begin to understand that there are other tools more suited for the job. Unfortunately, especially for students at well-known universities, learning a language often opens the door to a cult. I remember the "Pascal cult", the "forth cult", the "C cult" the "C++ cult", and now the "C# cult". Next year there may be "D" and the cycle will continue. Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 18:39 ` Richard B. Johnson @ 2004-01-19 20:02 ` Bart Samwel 2004-01-19 20:37 ` Richard B. Johnson 0 siblings, 1 reply; 25+ messages in thread From: Bart Samwel @ 2004-01-19 20:02 UTC (permalink / raw) To: root; +Cc: Ashish sddf, Linux kernel Richard B. Johnson wrote: > On Mon, 19 Jan 2004, Bart Samwel wrote: [... lots of text ...] >>I'm not familiar with the exact history of the project, but I expect >>that they decided to do C++ because the model they try to express is >>best modeled using C++. This design decision can be debated, because it >>is perfectly feasible (albeit with a lot more work) to implement an OO >>model in C. In fact, I have helped to implement a similar framework (the >>OKE CORRAL) which was written completely in C. But, the fact of the >>matter is, this useful (but huge) kernel module is there now (and it has >>been here since the early 2.2 kernels), and it was not written just to >>"prove" that it could be done, but because C++ seemed at the time to be >>the best language for the job. The start of this project may very well >>predate the many times that this was hashed-over on the LKML >>(disclaimer: I wasn't there, so I don't know). You refer to "what can >>only be" the arrogance of the writers, yet continue by claiming: >> >> > I'd suggest that you spend some time converting it to C if you need >> > that "module". >> >>and >> >> > The conversion will surely take less time than going through the >> > kernel headers looking for "::". >> >>Excuse me, but before calling somebody else arrogant, I would suggest >>that you might want check whether you're not calling the kettle black. >>It's not a sign of modesty when you assume without a trace of doubt that >>a module (that happened to have been developed over the course of four >>years by a team of people at MIT) is just a "\"module\"" and that it >>will take less time to port it to C than to make the kernel headers >>parse in a C++ extern "C" clause. In addition, imagine how you would >>feel if somebody referred to your work as a "\"module\""! The fact that >>you "can't imagine why anybody would even attempt to write a kernel >>module in C++" may just as well be due to a lack of imagination on your >>side, but in your statement I detect no trace of a doubt. And _yes_ you >>may very well be right about their initial decision being stupid (and >>you might not be -- I don't know), and _yes_ you are probably right >>about the whole thing being hashed-over many times (I don't know -- I >>wasn't there), and _yes_ there are people out there who would do >>anything just to prove they can do something others think is impossible >>or just filthy. So, yes, there _may_ be a point to what you're saying. >>_May_. I'm not saying you're wrong, and I'm not saying you're right. >>What I'm saying is that simply assuming that any C++ module is nothing >>more than a few lines of (de)glorified C and accusing the writers of >>being arrogant just because they wrote a kernel module in C++ is, in my >>opinion, jumping to conclusions based on >>technical-preference-turned-prejudice (at least, that's how it seems), >>and it's not very polite either. > > The possibility that something may have been written by some MIT people > can't change the fact that C++ is not the tool that should have been > used within the kernel. I once worked on a project at Princeton. That > doesn't make me know anything about Relativity. Einstein didn't rub > off due to some proximity effect. No. But the fact that you haven't seen the module means that you can't possibly know whether the module is a "\"module\"" or just a "module" -- there are probably solid technical reasons to dislike C++ in the kernel, but that is no excuse to start calling things "\"module\"" instead of just "module". The fact that you're now attacking this minor point (the fact that these people happen to be MIT people) means that you missed the major point -- you were jumping to conclusions and calling people arrogant without checking the specific background, and without reserve. I usually think it's wise to *either* not check the background *or* keep no reserve, but not both. But that's just me. :) > If the "MIT Team", as you so state, had actually inspected some > kernel code, and actually understood what a Linux/Unix kernel does, > then learned persons could not possibly have selected C++ for this > project. > > If you review the project, you will probably also find that a > large percentage of the code should have been implemented in > user-mode (a daemon, or several). That's where C++ really shines. For most projects, you might be right. For this project, I think you're not. This project implements a new network router design, one that is aimed at achieving the best possible routing performance that can be achieved while maintaining maximum flexibility. The flexibility is achieved by having large amounts of configurable elements available, so that practically any routing task can be composed of the available elements. To achieve enough speed (and lack of latency) to be really viable as a router, they need to be as close to the hardware as possible. See it like this: as soon as pkttables can be moved to userspace with negligible performance loss, this app will be able to move too. > However, it wasn't. Which, to me, means that the developers > were either clue-less or, once somebody actually figured out > how a kernel works, it was way too late to change (an all to common > problem). The router code of the project works both in userspace and in kernel-space. It just works much slower in userspace. If they were able to get the right kind of performance in userspace they probably would. AFAIK these guys were also very early in the adoption of polling, according to the changelog they built polling support in April 2000. This got them a 4-5x speed increase. Not your typical project that you can make a daemon -- unless you're working in a microkernel OS, of course. Definitely not in Linux 2.2. > The number of persons who worked on a project does not affect the > correctness of the tools nor the architecture chosen. Facts are > not democratic. You can't vote them into or out of existence. The main point of that phrase was to indicate that more than four person-years went into this module. It didn't have anything to do with facts regarding correctness nor architecture, only with the fact that you stated without much reserve something that led me to believe that you had not considered that the size of this module may be larger than you imagined. >>Unfortunately, this is how flame wars get started (as can be seen by the >>slightly agitated tone this message has taken, sorry about that! :) ). >>Just to make this clear to everyone: I'm not trying to instigate a flame >>war here about C vs. C++, as I don't really have an opinion on that >>subject. This posting has to do with my preferences w.r.t. personal >>style, and nothing with my technical preferences. > > This is not about preferences. Most software engineers wish that > everything could be done using the first language they learned. Once > they try to write a state-machine in FORTRAN (my native language), they > begin to understand that there are other tools more suited for the > job. Unfortunately, especially for students at well-known universities, > learning a language often opens the door to a cult. I remember > the "Pascal cult", the "forth cult", the "C cult" the "C++ cult", and > now the "C# cult". Next year there may be "D" and the cycle will > continue. Yes, I know how this works. Although I have never programmed in FORTRAN, I have at least 15 other languages on my list (covering all of the well-known paradigms), not counting scripting languages, and I know that there is definitely a thing such as "the right tool for the right job". I do not dispute that. What I care about is your response, which seemed to indicate that you had already grouped the module authors in the "C++ cult" category, without keeping open the possibility that they might not be. You had already called them arrogant without checking any background. I don't care if they _are_ part of the "C++ cult", as you call it, but you had not enough information at this point to derive that. It seems that you're so allergic to the idea of mixing C++ with the kernel that you're blocking all possibility of discussion immediately. Calling somebody "arrogant" before they can even tell you why they did what they did is a perfect way to prevent any reasonable conversation from happening. It's not productive towards solving the problem at hand, and also not towards convincing people of your opinion. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 20:02 ` Bart Samwel @ 2004-01-19 20:37 ` Richard B. Johnson 2004-01-19 21:24 ` Bart Samwel 2004-01-20 0:59 ` Robin Rosenberg 0 siblings, 2 replies; 25+ messages in thread From: Richard B. Johnson @ 2004-01-19 20:37 UTC (permalink / raw) To: Bart Samwel; +Cc: Ashish sddf, Linux kernel On Mon, 19 Jan 2004, Bart Samwel wrote: > Richard B. Johnson wrote: > > On Mon, 19 Jan 2004, Bart Samwel wrote: > [... lots of text ...] [Snipped...] I stand by my assertion that anybody who develops kernel modules in C++, including MIT students, is arrogant. Let's see if C++ is in use in the kernel. At one time, some of the tools that came with it were written in C++ (like ksymoops). Script started on Mon Jan 19 15:19:33 2004 $ cd /usr/src/linux-2.4.24 $ find . -name "*.cpp" $ exit exit Script done on Mon Jan 19 15:20:25 2004 Well, perhaps the kernel developers were ignorant. They didn't write anything in C++. Maybe they were just too dumb to learn the language? Maybe there is another reason: The kernel development languages, as previously stated, were defined at the project's inception to be the GNU C 'gcc' compiler's "C" and extensions, and the 'as' (AT&T syntax) assembler. Anybody can search the archives for the discussions about using C++ in the kernel. Any person, or group of persons, who is smart enough to actually write some kernel code in C++, has proved that they are not ignorant. Therefore, they have demonstrated their arrogance. Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 20:37 ` Richard B. Johnson @ 2004-01-19 21:24 ` Bart Samwel 2004-01-20 15:20 ` Richard B. Johnson 2004-01-21 17:01 ` Giuliano Pochini 2004-01-20 0:59 ` Robin Rosenberg 1 sibling, 2 replies; 25+ messages in thread From: Bart Samwel @ 2004-01-19 21:24 UTC (permalink / raw) To: root; +Cc: Ashish sddf, Linux kernel Richard B. Johnson wrote: [...] > I stand by my assertion that anybody who develops kernel > modules in C++, including MIT students, is arrogant. > > Let's see if C++ is in use in the kernel. At one time, some > of the tools that came with it were written in C++ (like ksymoops). > > Script started on Mon Jan 19 15:19:33 2004 > $ cd /usr/src/linux-2.4.24 > $ find . -name "*.cpp" > $ exit > exit > Script done on Mon Jan 19 15:20:25 2004 Just so that you know, the extension .cpp is typically used by Windows C++ programmers, on most other environments the usual extensions are .cc and .C. If you look for *.cc you find scripts/kconfig/qconf.cc, so the kernel toolset is not completely C++-free. Not that all of this matters. > Well, perhaps the kernel developers were ignorant. They didn't > write anything in C++. Maybe they were just too dumb to learn the > language? It seems you you assume I'm an arrogant Bjarne-hugging C++-lover. Where did you get that? It's probably in your mind, where everyone who suggests C++ is a Bjarne-hugging C++-lover. I'M NOT IN THE C++ CULT. I'M NOT SAYING THAT EVERYONE SHOULD PROGRAM IN C++. Hope this came across, you are now officially declared deaf. ;) > Maybe there is another reason: > The kernel development languages, as previously stated, were > defined at the project's inception to be the GNU C 'gcc' > compiler's "C" and extensions, and the 'as' (AT&T syntax) > assembler. Anybody can search the archives for the discussions > about using C++ in the kernel. Yeah, definitely. I fully agree that it's not wise to use C++ *in the base kernel*. The Linux project needs to maintain overall consistency, and one of the means of doing that is using a small, well-defined toolset -- in this case, as and gcc. Any large project needs language and coding standards. But we're not talking about the base kernel here. We're not talking about migrating the kernel to C++, or even modules that are part of the Linux kernel source. We're talking about *independent modules*. The kernel exports a module interface, and any binary driver that correctly hooks into the interface of the running kernel (using the correct calling conventions of the running kernel) and behaves properly (e.g., doesn't do stack unwinds over chunks of kernel functions etc.) can hook into it and do useful work. If somebody has decided that it would be worth it for his project to use C++ (without exceptions, rtti and the whole shebang) then so be it, why should you care? It's just binary code that hooks into the module interface, using the correct calling conventions. It doesn't do dirty stuff -- no exceptions, no RTTI, etcetera. It compiles into plain, module-interface conforming assembler, that can be compiled with -- you guessed it -- 'as', the AT&T syntax assembler. Yes, they're taking a risk. Their risk is that C++ can't import the kernel headers, or that C++ might someday need runtime support that cannot be ported into the kernel. It's *their risk*, not yours. Then why do you have a reason to get religious about this? They're not submitting this stuff for inclusion in the Linux source! > Any person, or group of persons, who is smart enough to > actually write some kernel code in C++, has proved that > they are not ignorant. Therefore, they have demonstrated > their arrogance. This logic is faulty. It is built upon the premise that (ignorant || arrogant). Not listening to warnings of others is not a sign of arrogance per se, it is only a sign of the presence of a different opinion. It assumes that the kernel developers are always right, and that everybody who is smart should listen to them, on penalty of being arrogant. Yes, these C++-loving people may be wrong (or they may not be), but that does not _automatically_ make them arrogant, they may simply have a different opinion -- right or wrong. If they are wrong, they are not arrogant, but simply *stupid*. If they are right, they are not arrogant either -- they may be arrogant *about it*, but that's just a manner of behaviour, and it's up to them if they behave in this way or not. Kernel developers do not prescribe what people can do with the kernel, this is part of the essence of "free". And as a result of that, they do not have the right to declare people arrogant when they do not listen. They have the right to *call* them that, but the only result of that is that all discussion on matters like these are smothered in religious wars. And that's a pity. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 21:24 ` Bart Samwel @ 2004-01-20 15:20 ` Richard B. Johnson 2004-01-20 17:34 ` Zan Lynx 2004-01-21 17:01 ` Giuliano Pochini 1 sibling, 1 reply; 25+ messages in thread From: Richard B. Johnson @ 2004-01-20 15:20 UTC (permalink / raw) To: Bart Samwel; +Cc: Ashish sddf, Linux kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 8018 bytes --] On Mon, 19 Jan 2004, Bart Samwel wrote: > Richard B. Johnson wrote: [SNIPPED...] > into it and do useful work. If somebody has decided that it would be > worth it for his project to use C++ (without exceptions, rtti and the > whole shebang) then so be it, why should you care? It's just binary code > that hooks into the module interface, using the correct calling > conventions. It doesn't do dirty stuff -- no exceptions, no RTTI, > etcetera. It compiles into plain, module-interface conforming assembler, > that can be compiled with -- you guessed it -- 'as', the AT&T syntax > assembler. Yes, they're taking a risk. Their risk is that C++ can't > import the kernel headers, or that C++ might someday need runtime > support that cannot be ported into the kernel. It's *their risk*, not > yours. Then why do you have a reason to get religious about this? > They're not submitting this stuff for inclusion in the Linux source! > > > Any person, or group of persons, who is smart enough to > > actually write some kernel code in C++, has proved that > > they are not ignorant. Therefore, they have demonstrated > > their arrogance. > > This logic is faulty. It is built upon the premise that (ignorant || > arrogant). Not listening to warnings of others is not a sign of > arrogance per se, it is only a sign of the presence of a different > opinion. It assumes that the kernel developers are always right, and > that everybody who is smart should listen to them, on penalty of being > arrogant. Yes, these C++-loving people may be wrong (or they may not > be), but that does not _automatically_ make them arrogant, they may > simply have a different opinion -- right or wrong. If they are wrong, > they are not arrogant, but simply *stupid*. If they are right, they are > not arrogant either -- they may be arrogant *about it*, but that's just > a manner of behaviour, and it's up to them if they behave in this way or > not. Kernel developers do not prescribe what people can do with the > kernel, this is part of the essence of "free". And as a result of that, > they do not have the right to declare people arrogant when they do not > listen. They have the right to *call* them that, but the only result of > that is that all discussion on matters like these are smothered in > religious wars. And that's a pity. It's not, as you say, a religious war. Whether or not one can use the back-end of a hatchet as a hammer does not qualify the hatchet as a hammer. Let me introduce the concept of a "learned person". Such a person might not actually exist. However, for my proposes, a learned person knows everything there is to know about solving the problem at hand. This is a definition. It is not subject to discussion. C++ was designed as an object-oriented language. C and assembler are procedural languages, as have been most all previous programming languages. The coding of operating systems is all about procedures. In fact, one of the reasons for the superiority of Linux is the great attention to the details of the actual execution mechanisms and the actual execution paths. An object-oriented language relies upon the compiler and libraries to work out the execution mechanisms to be used. The programmer is shielded from the actual mechanisms that implement the objects being manipulated. For instance, in C, one can code a loop counter and code the actual mechanisms by which a procedure may terminate. In C++, one may use iterators. Whether or not there is some actual counter is an implementation detail that can be hidden from the programmer. Of course one may also write C-like code when using C++ because there are some things that an object- oriented mechanism can't do by itself. This allows one to write loops with loop-counters in C++. The fact that C++ can be used somewhat like C does not make it a substitute for C anymore than a hatchet is a substitute for a hammer. Because of the object-oriented design of C++, there is considerable overhead necessary to make it function in an environment with many other objects. C has some overhead of its own, too. However, it is quite minimal. Local variable space is allocated simply by subtracting a value from the stack-pointer, for instance. The overhead of a particular language is often demonstrated by writing a simple "Hello World!" program in that language and then displaying the result as the size of the executable. This, of course, is quite unfair. It really shows how smart the linker is. A smart linker will link in only the required code. Linkers are pretty dumb. In the kernel, a linker doesn't have to be smart because the programmers have provided only the code that should be executed. There is no runtime library. Nevertheless, I provide three programs, one written in C, the other in C++ and the third in assembly. A tar.gz file is attached for those interested. -rwxr-xr-x 1 root root 57800 Jan 20 10:16 hello+ -rwxr-xr-x 1 root root 460 Jan 20 10:16 helloa -rwxr-xr-x 1 root root 2948 Jan 20 10:16 helloc The code size, generated from assembly is 460 bytes. The code size, generated from C is 2,948 bytes. The code size, generated from C++ is 57,800 bytes. Clearly, C++ is not the optimum language for writing a "Hello World" program. Because many persons don't know assembly language, it is probably not the best language either, in spite of the fact that the executable file is only 460 bytes in length. Therefore a learned person, given the task of choosing the language in which to write "Hello World!" would likely use 'C'. In spite of the fact that it can be written in C++, I suggest, in fact insist, that a learned person would never write such a program in C++ except for the purpose of demonstrating that it can be done. When writing code for a project, one is not usually presented with a bunch of languages from which one can choose on a whim, or by throwing darts. Instead, there are specific requirements defined by the nature of the work to be done. There is no learned person who would require that a data-base project be written in assembler. It is quite likely that the optimum language would be C++. There might be certain portions of the resulting executable that, in fact, were written in assembler, probably a lot of the runtime library. When writing a data-base program, one absolutely positively must not know what the underlying data-fetching mechanisms are because, once known and used to define (poison) the design, the program may run poorly on a network. This is one of the areas where object-oriented programming really shines. However, when writing code that runs in an Operating System, one is most entirely concerned, in fact consumed with the mechanisms by which the required functionality is obtained. Programmers spend hours, days, even weeks, shaving microseconds off from critical execution paths. This is because any resources used by the Operating System directly affect every task running under that Operating System. A learned person would never allow the code, defined by the designers of a compiler, to make the final decision about the mechanisms necessary to perform the required functions. Instead, the Operating System programmer makes those decisions. That's why a procedural language must be used in coding Operating Systems. The result of such attention to details is the Linux Operating System. Now, if you want to trash your copy of the Operating System with the output spewed from a C++ compiler, then I suggest you keep it real quiet. It is similar to "touching up" a famous painting with spray-paint, of defecating on a wedding cake. Again, writing a Linux kernel module in C++ demonstrates arrogance, absolutely, positively arrogance, and is an affront to the programmers who have dedicated major amounts of their time optimizing code execution in the kernel. Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. [-- Attachment #2: Type: APPLICATION/octet-stream, Size: 674 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 15:20 ` Richard B. Johnson @ 2004-01-20 17:34 ` Zan Lynx 2004-01-20 18:10 ` Richard B. Johnson 2004-01-20 18:16 ` Chris Friesen 0 siblings, 2 replies; 25+ messages in thread From: Zan Lynx @ 2004-01-20 17:34 UTC (permalink / raw) To: root; +Cc: Bart Samwel, Ashish sddf, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] On Tue, 2004-01-20 at 08:20, Richard B. Johnson wrote: > Nevertheless, I provide three programs, one written in > C, the other in C++ and the third in assembly. A tar.gz > file is attached for those interested. > > -rwxr-xr-x 1 root root 57800 Jan 20 10:16 hello+ > -rwxr-xr-x 1 root root 460 Jan 20 10:16 helloa > -rwxr-xr-x 1 root root 2948 Jan 20 10:16 helloc > > The code size, generated from assembly is 460 bytes. > The code size, generated from C is 2,948 bytes. > The code size, generated from C++ is 57,800 bytes. > > Clearly, C++ is not the optimum language for writing > a "Hello World" program. I like C++ and hate to see it so unfairly maligned. Here's a much better example: Makefile: helloc: hello.c gcc -Os -s -o helloc hello.c hellocpp: hello.cpp g++ -Os -fno-rtti -fno-exceptions -s -o hellocpp hello.cpp Both programs contain exactly the same code: one main() function using puts("Hello world!"). # ls -l -rwxrwxr-x 1 jbriggs jbriggs 2840 Jan 20 10:02 helloc -rwxrwxr-x 1 jbriggs jbriggs 2948 Jan 20 10:06 hellocpp 108 extra bytes is hardly the end of the world. -- Zan Lynx <zlynx@acm.org> [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 17:34 ` Zan Lynx @ 2004-01-20 18:10 ` Richard B. Johnson 2004-01-20 13:38 ` Thomas Lahoda 2004-01-21 2:24 ` Michael Clark 2004-01-20 18:16 ` Chris Friesen 1 sibling, 2 replies; 25+ messages in thread From: Richard B. Johnson @ 2004-01-20 18:10 UTC (permalink / raw) To: Zan Lynx; +Cc: Bart Samwel, Ashish sddf, Linux Kernel Mailing List On Tue, 20 Jan 2004, Zan Lynx wrote: > On Tue, 2004-01-20 at 08:20, Richard B. Johnson wrote: > > Nevertheless, I provide three programs, one written in > > C, the other in C++ and the third in assembly. A tar.gz > > file is attached for those interested. > > > > -rwxr-xr-x 1 root root 57800 Jan 20 10:16 hello+ > > -rwxr-xr-x 1 root root 460 Jan 20 10:16 helloa > > -rwxr-xr-x 1 root root 2948 Jan 20 10:16 helloc > > > > The code size, generated from assembly is 460 bytes. > > The code size, generated from C is 2,948 bytes. > > The code size, generated from C++ is 57,800 bytes. > > > > Clearly, C++ is not the optimum language for writing > > a "Hello World" program. > > I like C++ and hate to see it so unfairly maligned. Here's a much > better example: > > Makefile: > helloc: hello.c > gcc -Os -s -o helloc hello.c > > hellocpp: hello.cpp > g++ -Os -fno-rtti -fno-exceptions -s -o hellocpp hello.cpp > > Both programs contain exactly the same code: one main() function using > puts("Hello world!"). > > # ls -l > -rwxrwxr-x 1 jbriggs jbriggs 2840 Jan 20 10:02 helloc > -rwxrwxr-x 1 jbriggs jbriggs 2948 Jan 20 10:06 hellocpp > > 108 extra bytes is hardly the end of the world. > -- > Zan Lynx <zlynx@acm.org> > Well you just fell into the usual trap of using the "C-like" capabilities of C++ to call a 'C' function. If you are going to use 'C' library functions, you don't use an object-oriented language to call them. That is using a hatchet like a hammer. I did not malign C++. I used it as it was designed and let the chips fall where they may. Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 18:10 ` Richard B. Johnson @ 2004-01-20 13:38 ` Thomas Lahoda 2004-01-21 2:24 ` Michael Clark 1 sibling, 0 replies; 25+ messages in thread From: Thomas Lahoda @ 2004-01-20 13:38 UTC (permalink / raw) To: linux-kernel Not that I'm calling for the use of c++ in a kernel, but if you're going to argue against it you should get your c++ example correct. You are erroneously using fstream to get your cout. In c++, cout is an ostream object. With the above correction compiled using g++ 3.3.2 I get the following: -rwxrwxr-x 1 tlahoda tlahoda 3820 Jan 20 13:27 hello+ -rwxrwxr-x 1 tlahoda tlahoda 2760 Jan 20 13:30 helloc On Tue, 2004-01-20 at 18:10, Richard B. Johnson wrote: > On Tue, 20 Jan 2004, Zan Lynx wrote: > > > On Tue, 2004-01-20 at 08:20, Richard B. Johnson wrote: > > > Nevertheless, I provide three programs, one written in > > > C, the other in C++ and the third in assembly. A tar.gz > > > file is attached for those interested. > > > > > > -rwxr-xr-x 1 root root 57800 Jan 20 10:16 hello+ > > > -rwxr-xr-x 1 root root 460 Jan 20 10:16 helloa > > > -rwxr-xr-x 1 root root 2948 Jan 20 10:16 helloc > > > > > > The code size, generated from assembly is 460 bytes. > > > The code size, generated from C is 2,948 bytes. > > > The code size, generated from C++ is 57,800 bytes. > > > > > > Clearly, C++ is not the optimum language for writing > > > a "Hello World" program. > > > > I like C++ and hate to see it so unfairly maligned. Here's a much > > better example: > > > > Makefile: > > helloc: hello.c > > gcc -Os -s -o helloc hello.c > > > > hellocpp: hello.cpp > > g++ -Os -fno-rtti -fno-exceptions -s -o hellocpp hello.cpp > > > > Both programs contain exactly the same code: one main() function using > > puts("Hello world!"). > > > > # ls -l > > -rwxrwxr-x 1 jbriggs jbriggs 2840 Jan 20 10:02 helloc > > -rwxrwxr-x 1 jbriggs jbriggs 2948 Jan 20 10:06 hellocpp > > > > 108 extra bytes is hardly the end of the world. > > -- > > Zan Lynx <zlynx@acm.org> > > > > Well you just fell into the usual trap of using the "C-like" > capabilities of C++ to call a 'C' function. If you are going > to use 'C' library functions, you don't use an object-oriented > language to call them. That is using a hatchet like a hammer. > > I did not malign C++. I used it as it was designed and let > the chips fall where they may. > > Cheers, > Dick Johnson > Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). > Note 96.31% of all statistics are fiction. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 18:10 ` Richard B. Johnson 2004-01-20 13:38 ` Thomas Lahoda @ 2004-01-21 2:24 ` Michael Clark 1 sibling, 0 replies; 25+ messages in thread From: Michael Clark @ 2004-01-21 2:24 UTC (permalink / raw) To: root; +Cc: Zan Lynx, Bart Samwel, Ashish sddf, Linux Kernel Mailing List On 01/21/04 02:10, Richard B. Johnson wrote: > > Well you just fell into the usual trap of using the "C-like" > capabilities of C++ to call a 'C' function. If you are going > to use 'C' library functions, you don't use an object-oriented > language to call them. That is using a hatchet like a hammer. > > I did not malign C++. I used it as it was designed and let > the chips fall where they may. Apple has succedded in using C++ in their kernel. Its IOKit uses an embedded subset of C++ (no exceptions, RTTI, non-trivial descructors, etc) as part of their device driver framework. The features they keep; polymorhism, inheritance, encapsulation provide for a very clean and easily extensible framework. Writing IOKit drivers is much cleaner than using plain C without out all the structures with pointers to functions (explicit implementation of virtual functions and a lot of casting of (void*) and/or unions). http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/About/chapter_1_section_1.html Although this could all be done in C (as is all the OO stuff in linux like VFS, block and chardevs, etc), it is certainly much cleaner in C++. Although horses for courses, we all know C++ won't fly in the linux kernel. Just I think 'embedded C++' which is an actual specification and a genuine superset of C and subset of C++ retaining safre features for kernels can't be ruled on on technical merits but rather only on personal opinion of language choice. Personally i prefer Linux's more explicit OO implmentation with the use of stuctures with pointers to functions (virtual functions) although not sure there is a really clean pattern used for inheritance (unions and void* private pointers) and encapsulation (static function bounday). ~mc ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 17:34 ` Zan Lynx 2004-01-20 18:10 ` Richard B. Johnson @ 2004-01-20 18:16 ` Chris Friesen 1 sibling, 0 replies; 25+ messages in thread From: Chris Friesen @ 2004-01-20 18:16 UTC (permalink / raw) To: Zan Lynx; +Cc: root, Bart Samwel, Ashish sddf, Linux Kernel Mailing List Zan Lynx wrote: > I like C++ and hate to see it so unfairly maligned. Here's a much > better example: > Both programs contain exactly the same code: one main() function using > puts("Hello world!"). Just to pick a nit, if you use cout (as most C++ people would) the size goes up by another couple hundred bytes. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 21:24 ` Bart Samwel 2004-01-20 15:20 ` Richard B. Johnson @ 2004-01-21 17:01 ` Giuliano Pochini 2004-01-21 17:16 ` Bart Samwel 1 sibling, 1 reply; 25+ messages in thread From: Giuliano Pochini @ 2004-01-21 17:01 UTC (permalink / raw) To: Bart Samwel; +Cc: root, Ashish sddf, Linux kernel On Mon, 19 Jan 2004, Bart Samwel wrote: > But we're not talking about the base kernel here. We're not talking > about migrating the kernel to C++, or even modules that are part of the > Linux kernel source. We're talking about *independent modules*. The > kernel exports a module interface, and any binary driver that correctly > hooks into the interface of the running kernel (using the correct > calling conventions of the running kernel) and behaves properly (e.g., > doesn't do stack unwinds over chunks of kernel functions etc.) can hook > into it and do useful work. If somebody has decided that it would be > worth it for his project to use C++ (without exceptions, rtti and the > whole shebang) then so be it, why should you care? It's just binary code > that hooks into the module interface, using the correct calling > conventions. It doesn't do dirty stuff -- no exceptions, no RTTI, > etcetera. It compiles into plain, module-interface conforming assembler, > that can be compiled with -- you guessed it -- 'as', the AT&T syntax > assembler. Yes, they're taking a risk. Their risk is that C++ can't > import the kernel headers, or that C++ might someday need runtime > support that cannot be ported into the kernel. I managed to use a a lot of C++ code in a kernel modules. I used wrapper functions to pass data between C and C++ parts. C++ code had no exceptions and such thing, but I had to play some dirty tricks anyway because C++ code needs stuff which is provided by userpace libraries to run. Maybe the right solution is writing a module that provides a fast data path between the kernel and the userspace router. -- Giuliano. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-21 17:01 ` Giuliano Pochini @ 2004-01-21 17:16 ` Bart Samwel 0 siblings, 0 replies; 25+ messages in thread From: Bart Samwel @ 2004-01-21 17:16 UTC (permalink / raw) To: Giuliano Pochini; +Cc: Ashish sddf, Linux kernel Giuliano Pochini wrote: > On Mon, 19 Jan 2004, Bart Samwel wrote: >>But we're not talking about the base kernel here. We're not talking >>about migrating the kernel to C++, or even modules that are part of the >>Linux kernel source. We're talking about *independent modules*. The >>kernel exports a module interface, and any binary driver that correctly >>hooks into the interface of the running kernel (using the correct >>calling conventions of the running kernel) and behaves properly (e.g., >>doesn't do stack unwinds over chunks of kernel functions etc.) can hook >>into it and do useful work. If somebody has decided that it would be >>worth it for his project to use C++ (without exceptions, rtti and the >>whole shebang) then so be it, why should you care? It's just binary code >>that hooks into the module interface, using the correct calling >>conventions. It doesn't do dirty stuff -- no exceptions, no RTTI, >>etcetera. It compiles into plain, module-interface conforming assembler, >>that can be compiled with -- you guessed it -- 'as', the AT&T syntax >>assembler. Yes, they're taking a risk. Their risk is that C++ can't >>import the kernel headers, or that C++ might someday need runtime >>support that cannot be ported into the kernel. [...] > Maybe the right solution is writing a module that provides a fast data > path between the kernel and the userspace router. Hmmm, I think that would be problematic. The throughput would probably be relatively OK (it's perfectly feasible to stash a load of packets into an mmapped area with zero copies and to have them all routed in userspace) but the latency is a different story. A router should be able to pass on packets with the lowest possible latency. I don't think it's feasible to schedule a userspace router process for every packet that comes in (they can currently do 435,000 packets per second on a P3-700), so that would have to be done in bulk, and that's a killer for your latency. AFAICS the right solution would be to do it in the kernel and not to use C++ for it. It's a bit late for that now though. :) -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 20:37 ` Richard B. Johnson 2004-01-19 21:24 ` Bart Samwel @ 2004-01-20 0:59 ` Robin Rosenberg 2004-01-20 6:46 ` Linus Torvalds 1 sibling, 1 reply; 25+ messages in thread From: Robin Rosenberg @ 2004-01-20 0:59 UTC (permalink / raw) To: Linux kernel måndagen den 19 januari 2004 21.37 skrev Richard B. Johnson: > Let's see if C++ is in use in the kernel. At one time, some > of the tools that came with it were written in C++ (like ksymoops). > > Script started on Mon Jan 19 15:19:33 2004 > $ cd /usr/src/linux-2.4.24 > $ find . -name "*.cpp" > $ exit > exit > Script done on Mon Jan 19 15:20:25 2004 > This is the "We've always used COBOL^H^H^H^H" argument. -- robin ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 0:59 ` Robin Rosenberg @ 2004-01-20 6:46 ` Linus Torvalds 2004-01-20 7:32 ` Robin Rosenberg 2004-01-20 10:46 ` Bart Samwel 0 siblings, 2 replies; 25+ messages in thread From: Linus Torvalds @ 2004-01-20 6:46 UTC (permalink / raw) To: Robin Rosenberg; +Cc: Linux kernel On Tue, 20 Jan 2004, Robin Rosenberg wrote: > > This is the "We've always used COBOL^H^H^H^H" argument. In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so. Feel free to make up (d). Linus ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 6:46 ` Linus Torvalds @ 2004-01-20 7:32 ` Robin Rosenberg 2004-01-20 10:46 ` Bart Samwel 1 sibling, 0 replies; 25+ messages in thread From: Robin Rosenberg @ 2004-01-20 7:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List tisdagen den 20 januari 2004 07.46 skrev du: > On Tue, 20 Jan 2004, Robin Rosenberg wrote: > > > > This is the "We've always used COBOL^H^H^H^H" argument. > > In fact, in Linux we did try C++ once already, back in 1992. > > It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. > I know C++ in and out. I love it and hate it. I had a nightmare once in which I a had convinced a friend how wonderful C++ is. A while later he came back., and he was mad. > The fact is, C++ compilers are not trustworthy. They were even worse in > 1992, but some fundamental facts haven't changed: > [snip] Now THAT is the reason. -- robin ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 6:46 ` Linus Torvalds 2004-01-20 7:32 ` Robin Rosenberg @ 2004-01-20 10:46 ` Bart Samwel 1 sibling, 0 replies; 25+ messages in thread From: Bart Samwel @ 2004-01-20 10:46 UTC (permalink / raw) To: Linus Torvalds; +Cc: Robin Rosenberg, Linux kernel Linus Torvalds wrote: > The fact is, C++ compilers are not trustworthy. They were even worse in > 1992, but some fundamental facts haven't changed: > > - the whole C++ exception handling thing is fundamentally broken. It's > _especially_ broken for kernels. I second that. The basic reason the C++ exception handling mechanism is broken is because of what happens when an exception is thrown from a destructor, during a stack unwind caused by an exception. There are paths of exception/destructor combinations that you just cannot get out of correctly. This is perfectly OK for most userland apps, but for kernels it's definitely not OK. > - any compiler or language that likes to hide things like memory > allocations behind your back just isn't a good choice for a kernel. True, when you're doing code that requires locking etc. you don't want a destructor coming in and deallocating something that you haven't locked. I don't see when C++ can hide memory *allocations* though, any more than C can hide them behind trees of function calls. > - you can write object-oriented code (useful for filesystems etc) in C, > _without_ the crap that is C++. True, C++ _is_ full of crap -- that's what C++ lovers refer to as "power". For work, I program in C++, and I love it because of the power of expression. I hate it because of the amount of rope it gives me to hang myself with. And because most C++ compilers are _so_ immature. Still, OO can be written in C (cfront does it :) ) but it's not always convenient. Especially when you're doing inheritance-like things, your C code will be sprinkled with casts (neatly hidden in macros, probably), and no C compiler will typecheck that. More static checking is good, I'd say, so there might be reasons to do C++ if you might otherwise get bogged down in a sea of casts. > In general, I'd say that anybody who designs his kernel modules for C++ is > either > (a) looking for problems Mostly true, I guess. But sometimes, if you stick to a wisely chosen subset, it can work out OK. For instance, exceptions should not be used. Destructors become much less of a problem when you rule out exceptions, and especially when combined it with lock objects for the locks. And it is very well possible to write C++ that is low on allocations, like kernel code should be. I think writing kernel code in C is also looking for problems, unless you know exactly what you're doing -- in that respect, it's pretty much the same. > (b) a C++ bigot that can't see what he is writing is really just C anyway This argument can, of course, be made for any language. In that case, the kernel developers' community can be said to be made up from C bigots that can't see that what they are writing is really just asm anyway. :) Anyway, I can definitely see your point if you think of people who use C++ as an "improved C", without much use of OO and templates etc. There are lots of people out there who do that, and transferring that mode of usage to the kernel is simply not a good idea. C++ should only be the language of choice when you need the things where it shines: inheritance hierarchies, templates, object finalization. My opinion is that if people want to use C++ in a module, they must do so: 1. Only if they _really_ need all that crap. 2. Only if they _really_ know what they're doing. 3. Only if they use a proper subset that cooperates correctly with the kernel. 4. Only if it's worth the extra effort that's needed to use C++ in a kernel module. Basically, I think that if you know the problems, and know them well, you don't need to go looking for them anymore, you might be able to just walk around them. Let's get back to the situation that started this discussion: the Click people have shown that they can walk around the problems (point 2), their code is true C++ (they seem to need all that crap, point 1) and it works fine inside it's own kernel module (point 3). Who are we to judge them, if it works for them? They don't really bother us with it -- we only bother ourselves with it *a lot* as soon as their existence is brought to our attention. :) And I think the only ones who can tell if it was worth the extra effort (point 4) are they themselves. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-19 17:40 ` Bart Samwel 2004-01-19 18:39 ` Richard B. Johnson @ 2004-01-20 5:29 ` Valdis.Kletnieks 2004-01-20 9:48 ` Bart Samwel 1 sibling, 1 reply; 25+ messages in thread From: Valdis.Kletnieks @ 2004-01-20 5:29 UTC (permalink / raw) To: Bart Samwel; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1543 bytes --] On Mon, 19 Jan 2004 18:40:18 +0100, Bart Samwel said: > Now, let me try to add a bit of nuance to your suggested solution. Try > porting 100s of C++ files (yes, it's that large) making heavy use of > inheritance etc. to C. Then try to make a bit of C code usable as extern > "C" in C++. Extern "C" was actually meant to be able to grok most C > code, while C++ wasn't meant to be easily portable to C. So, for any > moderately large module that uses any C++ features at all, it's probably > easier to make small syntactic changes to the kernel than to port the > module to C (which would amount to a full rewrite). That's one honking big module. Everybody please join me in a sigh of relief that the culprits didn't think Scheme was a suitable language. Anybody who thinks that C++ should be anywhere on the kernel side of the kernel/ user interface should understand why the kernel design doesn't even allow the use of *floating point* without much jumping through hoops. They then should ponder the political climate that created EXPORT_SYMBOL_GPL, which is (basically) a "this is OUR kernel and if you don't want to play by our rules, we intend to make things difficult for you". The module authors should then ask themselves what they're bringing to the table that's worth the kernel developers changing the way they do things. Unless there's a demonstrable reason or advantage to changing, the idea to support C++ is probably as dead-on-arrival as the heavily lambasted proposal to have a stable API for modules a while back. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-20 5:29 ` Valdis.Kletnieks @ 2004-01-20 9:48 ` Bart Samwel 0 siblings, 0 replies; 25+ messages in thread From: Bart Samwel @ 2004-01-20 9:48 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: linux-kernel Valdis.Kletnieks@vt.edu wrote: > On Mon, 19 Jan 2004 18:40:18 +0100, Bart Samwel said: > >>Now, let me try to add a bit of nuance to your suggested solution. Try >>porting 100s of C++ files (yes, it's that large) making heavy use of >>inheritance etc. to C. Then try to make a bit of C code usable as extern >>"C" in C++. Extern "C" was actually meant to be able to grok most C >>code, while C++ wasn't meant to be easily portable to C. So, for any >>moderately large module that uses any C++ features at all, it's probably >>easier to make small syntactic changes to the kernel than to port the >>module to C (which would amount to a full rewrite). > > That's one honking big module. Yeah, I think they could definitely have split it up a bit more. The inner workings are very modular however (it's built up of lots of relatively small classes), so splitting it up shouldn't be too hard, except that that would probably require exporting C++ symbols over module boundaries -- which is something they probably tried to avoid. It's one thing to run compiled C++ code (which basically amounts to running binary code that complies with the module interface of the running kernel) as a module, it's a completely different (and much more problematic) thing to place C++ symbols in the kernel symbol space. > Everybody please join me in a sigh of relief > that the culprits didn't think Scheme was a suitable language. Deep sigh! Luckily, Scheme didn't evolve from C, and it doesn't have a built-in compatibility layer that is specifically intended for C interoperability. If it did, there would probably be some idiot who would try it. :) (OT anecdote: a guy I met at the university once had to do a programming assignment where he had to do a stochastic experiment and print a graph of the results. The assignment didn't specify which language, so he wrote it in PostScript. Yes, _PostScript_, a language which, as I understand it, is not unlike Forth. Every time you would print out his document there would be a different graph, with results of a fresh stochastic experiment. :) ) > Anybody who thinks that C++ should be anywhere on the kernel side of the kernel/ > user interface should understand why the kernel design doesn't even allow the > use of *floating point* without much jumping through hoops. I'm well aware of the technical difficulties and all the problems that appear when you're going to use C++. However, the kernel developers have even limited themselves (with good reasons) to even a subset of C: much of the C runtime library is not available in the kernel, and floating point math is also looked at with extreme caution. The C equivalent of C++'s exceptions (setjmp/longjmp) are not available in the kernel, even though they are a part of regular C. Is it not possible to conceive a subset of C++ (e.g., no exceptions, no floating point math) that could work, with only minimal hoops? All in all, if you take a restricted enough subset of C++, you basically get something that corresponds to the same subset of C that the kernel uses. The original C++ compiler (cfront) even compiles to C, IIRC. (I'm not saying that supporting such a subset of C++ would be a good thing, just trying to put this into perspective a bit. As you say, even floating point takes hoop-jumping. But that is not a "Forbidden!" or a "Allowed!", it's basically a shade of gray in-between. I'm just pondering the *possibility* that there's such a shade in-between for C++ as well, for those willing to jump through the necessary hoops.) > They then should > ponder the political climate that created EXPORT_SYMBOL_GPL, which is > (basically) a "this is OUR kernel and if you don't want to play by our rules, > we intend to make things difficult for you". > The module authors should then ask themselves what they're bringing to the > table that's worth the kernel developers changing the way they do things. > Unless there's a demonstrable reason or advantage to changing, the idea to > support C++ is probably as dead-on-arrival as the heavily lambasted proposal to > have a stable API for modules a while back. Fortunately, the people have never asked the kernel developers to change. They've simply taken a language with an excellent C interoperability layer, which can compile to object code that contains only exported symbols with C-linkage, and they have restricted themselves to a subset of that language that doesn't break the C code they're interoperating with. This has become possible only because of the freeness of the kernel (which is encoded in the license and further enforced by things like EXPORT_SYMBOL_GPL), which allowed them to modify the kernel headers in order to get it to compile in an extern "C" clause in C++. They've maintained this patch since 2.2, and I don't expect this to change. I've even heard I don't think _they_ expect this to change, as they probably know all too well about the political climate within the kernel developers' scene. However, as long as the kernel keeps using C as it's language, keeps being GPL'ed, and keeps exporting a module interface that is defined by some prototypes in some C include files, I don't see how this could lead to any trouble for them. They can always maintain and distribute their patch (because of the freeness), they can always link in their C++ code as a module (because of the module layer) and they can always use the kernel's header files to import the module ABI for the current kernel (because they are C files, and because C++'s extern "C" will always be able to parse them -- except for some small fragments maybe, which might require a patch). So, the only trouble I can imagine them ever getting into is when the kernel developers *think* they are being asked to change their ways. That's bound to set them off into a frenzy of the-other-way-bashing, ad hominem attacks on the people who might even THINK about something like that etcetera. It's almost like it's a taboo. Well, in fact, it _is_ a taboo. :) Even if nobody has asked kernel developers to change their ways, even _mentioning_ something that is remotely related to this is immediately followed by an "allergic" reaction, like in this case. The only help Ashish wanted was with the build system, and the first response (Richard's) immediately attempted to figure out whether someone was serious about this or was only mistakenly trying to compile a userland program into the kernel. When it became clear that it was, in fact, serious, any further response had nothing to do with the build system (the original question) and everything with a gut reaction to the taboo being mentioned. I think that's a pity, as there was no reason for this kind of overreaction -- nobody outside the kernel developers group tried even remotely to change the kernel developers' ways, but the response from the kernel developers' group _was_ trying to change others' ways in response, and in a rather rude way too. I'm not trying to sway anyone either way here (as far as I'm concerned I'm not convinced either way, I'm not in a "camp"), I'm just opposed to the type of response this issue has brought up. The same could have been said in a polite, reasonable way with some reserves, and that would have saved us a lot of discussion and would have been much more productive as well. -- Bart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile 2004-01-16 21:09 Compiling C++ kernel module + Makefile Ashish sddf 2004-01-16 22:07 ` Richard B. Johnson @ 2004-01-16 22:40 ` Sam Ravnborg 1 sibling, 0 replies; 25+ messages in thread From: Sam Ravnborg @ 2004-01-16 22:40 UTC (permalink / raw) To: Ashish sddf; +Cc: linux-kernel > Does anyone can ideas about how to change the kernel > makefile to compile the C++ files the same way as C > files ? I assume you know the general opinion on C++ in the kernel - even in a module. I just did a quick untested hack - try this. It assumes extension .cc for c++ files. You also need to define CXX in top level makefile and export it. This patch will _not_ be pushed into mainline. Sam ===== scripts/Makefile.build 1.41 vs edited ===== --- 1.41/scripts/Makefile.build Sun Oct 5 08:50:46 2003 +++ edited/scripts/Makefile.build Fri Jan 16 23:39:26 2004 @@ -174,6 +174,23 @@ %.o: %.c FORCE $(call if_changed_rule,cc_o_c) +# C++ support + cmd_cc_o_cpp = $(CXX) $(c_flags) -c -o $@ $< +quiet_cmd_cc_o_cpp = C++ $@ + +define rule_cc_o_cpp + $(if $($(quiet)cmd_checksrc),echo ' $($(quiet)cmd_checksrc)';) \ + $(cmd_checksrc) \ + $(if $($(quiet)cmd_cc_o_cpp),echo ' $($(quiet)cmd_cc_o_cpp)';) \ + $(cmd_cc_o_cpp); \ + scripts/fixdep $(depfile) $@ '$(cmd_cc_o_cpp)' > $(@D)/.$(@F).tmp; \ + rm -f $(depfile); \ + mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd +endef + +%.o: %.cc FORCE + $(call if_changed_rule,cc_o_cpp) + # Single-part modules are special since we need to mark them in $(MODVERDIR) $(single-used-m): %.o: %.c FORCE ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Compiling C++ kernel module + Makefile
@ 2004-01-19 13:21 Petr Vandrovec
0 siblings, 0 replies; 25+ messages in thread
From: Petr Vandrovec @ 2004-01-19 13:21 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Ashish sddf, linux-kernel, bart
On 19 Jan 04 at 8:46, Richard B. Johnson wrote:
> On Sat, 17 Jan 2004, Bart Samwel wrote:
>
> > On Friday 16 January 2004 23:07, Richard B. Johnson wrote:
> > > If somebody actually got a module, written in C++, to compile and
> > > work on linux-2.4.nn, as you state, it works only by fiat, i.e., was
> > > declared to work. There is no C++ runtime support in the kernel for
> > > C++. Are you sure this is a module and not an application? Many
> > > network processes (daemons) are applications and they don't require
> > > any knowledge of kernel internals except what's provided by the
> > > normal C/C++ include-files.
> >
> > Rest assured, ;) this is definitely a module. It includes a kernel patch that
> > makes it possible to include a lot of the kernel headers into C++, stuff like
> > changing asm :: to asm : : (note the space, :: is an operator in C++) and
> > renaming "struct namespace" to something containing less C++ keywords. The
> > module also includes rudimentary C++ runtime support code, so that the C++
> > code will run inside the kernel. I'm afraid that the task of compiling it for
> > 2.6 is going to be pretty tough -- the kernel needs loads of patches to make
> > it work within a C++ extern "C" clause, and it probably completely different
> > patches from those needed by 2.4. Getting the build system to work is the
> > least of the concerns.
> >
> > -- Bart
> >
>
> I can't imagine why anybody would even attempt to write a kernel
> module in C++. Next thing it'll be Visual BASIC, then Java. The
> kernel is written in C and assembly. The tools are provided. It
> can only be arrogance because this whole C v.s. C++ thing was
> hashed-over many times. Somebody apparently wrote something to
> "prove" that it can be done. I'd suggest that you spend some
> time converting it to C if you need that "module". The conversion
> will surely take less time than going through the kernel headers
> looking for "::".
I doubt. I have module which uses templates to get support for
couple of possible userspace interfaces which existed over time,
and it works very well, without any changes to the kernel headers. Only
thing I had to do was:
#ifdef __cplusplus
# define new new_member
# define private private_member
# define namespace namespace_member
#endif
and extern "C" around #includes.
Of course that it is possible to do everything what templates do with
#define, but why do that in complicated ways if it can be done much
simpler?
Of course this module does not use exceptions or rtti, just templates
and static class members.
Module compiles on 2.2.0 to 2.6.1, with gcc 2.95-3.4. If you'll limit
yourself to gcc-3.0 or later, you do not have to worry about ::/: : at all,
as gcc's c++ parser gets it right after 2.95.
Petr Vandrovec
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2004-01-21 17:16 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-16 21:09 Compiling C++ kernel module + Makefile Ashish sddf 2004-01-16 22:07 ` Richard B. Johnson 2004-01-17 12:59 ` Bart Samwel 2004-01-19 13:46 ` Richard B. Johnson 2004-01-19 17:40 ` Bart Samwel 2004-01-19 18:39 ` Richard B. Johnson 2004-01-19 20:02 ` Bart Samwel 2004-01-19 20:37 ` Richard B. Johnson 2004-01-19 21:24 ` Bart Samwel 2004-01-20 15:20 ` Richard B. Johnson 2004-01-20 17:34 ` Zan Lynx 2004-01-20 18:10 ` Richard B. Johnson 2004-01-20 13:38 ` Thomas Lahoda 2004-01-21 2:24 ` Michael Clark 2004-01-20 18:16 ` Chris Friesen 2004-01-21 17:01 ` Giuliano Pochini 2004-01-21 17:16 ` Bart Samwel 2004-01-20 0:59 ` Robin Rosenberg 2004-01-20 6:46 ` Linus Torvalds 2004-01-20 7:32 ` Robin Rosenberg 2004-01-20 10:46 ` Bart Samwel 2004-01-20 5:29 ` Valdis.Kletnieks 2004-01-20 9:48 ` Bart Samwel 2004-01-16 22:40 ` Sam Ravnborg 2004-01-19 13:21 Petr Vandrovec
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.