kbuild: libraries and subdirectories
I have a large number of sources files, which I have to compile into one kernel module. Let's assume I have the following source organisation: main/ main_code.c lib1/ part1/ file_1_1_1.c part2/ file_1_2_1.c lib2/ part1/ file_2_1_1.c part2/ file_2_2_1.c I would like to build all source files in lib1 into one lib.a library and all files in lib2 into a second lib.a library. At the end I would like to compile the code in main and link every together (result should be one kernel module). How can I archieve this with kbuild? Its documentation is not really deep. I have added to all subdirectories kbuild files looking like this: lib-m = file_1_1_1.c This works and creates lib.a archives. In fact I have got two problems: *) How can I tell kbuild in lib1 and lib2 to descend into the part directories? *) How can I link the libraries of the part directories into libs in the lib directories? cu, Marco - 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/
kbuild: libraries and subdirectories
I have a large number of sources files, which I have to compile into one kernel module. Let's assume I have the following source organisation: main/ main_code.c lib1/ part1/ file_1_1_1.c part2/ file_1_2_1.c lib2/ part1/ file_2_1_1.c part2/ file_2_2_1.c I would like to build all source files in lib1 into one lib.a library and all files in lib2 into a second lib.a library. At the end I would like to compile the code in main and link every together (result should be one kernel module). How can I archieve this with kbuild? Its documentation is not really deep. I have added to all subdirectories kbuild files looking like this: lib-m = file_1_1_1.c This works and creates lib.a archives. In fact I have got two problems: *) How can I tell kbuild in lib1 and lib2 to descend into the part directories? *) How can I link the libraries of the part directories into libs in the lib directories? cu, Marco - 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/
RE: kbuild & C++
Hi, > Yes, this is a general problem with integrated c/c++ stuff like > Win-Visual C++. not all Windows users do not know what they are doing :-). Speaking for myself: I am programming under Linux and Windows (with more than 10 years experience in C and C++) and I do know the differences. So please do not call people idiots only because the are writing software under Windows. > People think that they can mix it freely, They can do. > in fact they > are using *only* C++ (it just happens that some part of the source is > compilable with a C compiler, but since you compile everything with the > C++ compiler pressing F9, no one sees the difference). So if I compile a library with gcc and link the code to a g++ program, the complete program gets compiled with the C++ compiler? Interesting :-). > Why do you think are all these "#ifdef _cpluplus" stuff in the header > files for? To support mixed code, because otherwise e.g. a C++ compiler cannot use a library compiled with a C compiler. > We re on linux-kernel@ here, so we don't care *here* for user-space > software (only for the interface - i.e. sys-calls). When you develop a complete product consisting of the embedded firmware, the driver, and the user space software, you always have to decide, where to put the code. And in such a case it is really nice, when you can use the same language in all layers. > And for embedded usage C++ is unsusable in user-space too since it will > ex-bloat the whole software if people simply pull-in usual and/or common > C++ libraries like the STL and use them without knowing how much object > code they explode with it (if used without thinking). This applies for all languages. If you do not know, what you are doing, you can write really awful code. And I cannot agree, that C++ results to larger code. > Which is again wrong. You can OO software without OO languages (though > you loose some nice features and checking). If you are an experienced OO programmer, you do not want to use languages like plain C, because they result into worse code and make life more difficult. If you do not like any kind of abstraction, why are you using C instead of pure assembler? > Is is impossible anyways since the in-kernel interfaces are probably > quite different (though I don't know anything about ). A lot of code (backend code) does not need any access to libraries/interfaces. > First, how much of it is really the source of a kernel driver (in the > sense of a Unix/Linux kernel driver)? At the moment you really need all the code to control all variants of the hardware. Yes, it is not a good design. We know it, our customer knows it, but at the moment we have to live with the situation. > And second, no one expects that you convert your driver source. Just > write it from scratch Can you estimate what such a redesign would cost our customers? You would need several years to redesign the concept. cu, Marco - 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/
RE: kbuild & C++
Hi, > Do you have any *serious* intent to drop 10 *megabytes* worth of driver > into the kernel??? (Hint - *everything* in drivers/net/wireless *totals* > to only 2.7M). no, I don't. No every module has to go into the standard kernel :-). > A Linux device driver isn't the same thing as a Windows device driver - much of > a Windows driver is considered "userspace" on Linux, and you're free to do that > in C++ if you want. Well, it is not the first driver I am writing for Linux. So yes, I do know, what is part of a Linux driver and what is not. cu, Marco - 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/
RE: kbuild & C++
Hi, >> That would be because the kernel is written in *C* (and some asm), *not* C++. I cannot see the connection. At the end everything gets converted to assembler/opcode. In the user space I can mix C and C++ code without any problems, why should this not be possible in the kernel mode? >> There /is/ no C++ support. This will be a problem in future. Nearly nobody will start a new larger project (driver, user space software, embedded firmware) using non OO languages today. So porting eg. Windows drivers to Linux is nearly impossible without C++ support. E.g. in my case the Windows source code has got more than 10 MB. Nobody will convert such an amount of code from C++ to C. This would take years. > I think it can only be a plus to Linux to add C++ support for at least > out-of-mainline drivers. Adding drivers written in C++ into the mainline > is another thing. Right. cu, Marco - 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/
RE: kbuild C++
Hi, That would be because the kernel is written in *C* (and some asm), *not* C++. I cannot see the connection. At the end everything gets converted to assembler/opcode. In the user space I can mix C and C++ code without any problems, why should this not be possible in the kernel mode? There /is/ no C++ support. This will be a problem in future. Nearly nobody will start a new larger project (driver, user space software, embedded firmware) using non OO languages today. So porting eg. Windows drivers to Linux is nearly impossible without C++ support. E.g. in my case the Windows source code has got more than 10 MB. Nobody will convert such an amount of code from C++ to C. This would take years. I think it can only be a plus to Linux to add C++ support for at least out-of-mainline drivers. Adding drivers written in C++ into the mainline is another thing. Right. cu, Marco - 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/
RE: kbuild C++
Hi, Do you have any *serious* intent to drop 10 *megabytes* worth of driver into the kernel??? (Hint - *everything* in drivers/net/wireless *totals* to only 2.7M). no, I don't. No every module has to go into the standard kernel :-). A Linux device driver isn't the same thing as a Windows device driver - much of a Windows driver is considered userspace on Linux, and you're free to do that in C++ if you want. Well, it is not the first driver I am writing for Linux. So yes, I do know, what is part of a Linux driver and what is not. cu, Marco - 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/
RE: kbuild C++
Hi, Yes, this is a general problem with integrated c/c++ stuff like Win-Visual C++. not all Windows users do not know what they are doing :-). Speaking for myself: I am programming under Linux and Windows (with more than 10 years experience in C and C++) and I do know the differences. So please do not call people idiots only because the are writing software under Windows. People think that they can mix it freely, They can do. in fact they are using *only* C++ (it just happens that some part of the source is compilable with a C compiler, but since you compile everything with the C++ compiler pressing F9, no one sees the difference). So if I compile a library with gcc and link the code to a g++ program, the complete program gets compiled with the C++ compiler? Interesting :-). Why do you think are all these #ifdef _cpluplus stuff in the header files for? To support mixed code, because otherwise e.g. a C++ compiler cannot use a library compiled with a C compiler. We re on linux-kernel@ here, so we don't care *here* for user-space software (only for the interface - i.e. sys-calls). When you develop a complete product consisting of the embedded firmware, the driver, and the user space software, you always have to decide, where to put the code. And in such a case it is really nice, when you can use the same language in all layers. And for embedded usage C++ is unsusable in user-space too since it will ex-bloat the whole software if people simply pull-in usual and/or common C++ libraries like the STL and use them without knowing how much object code they explode with it (if used without thinking). This applies for all languages. If you do not know, what you are doing, you can write really awful code. And I cannot agree, that C++ results to larger code. Which is again wrong. You can OO software without OO languages (though you loose some nice features and checking). If you are an experienced OO programmer, you do not want to use languages like plain C, because they result into worse code and make life more difficult. If you do not like any kind of abstraction, why are you using C instead of pure assembler? Is is impossible anyways since the in-kernel interfaces are probably quite different (though I don't know anything about ). A lot of code (backend code) does not need any access to libraries/interfaces. First, how much of it is really the source of a kernel driver (in the sense of a Unix/Linux kernel driver)? At the moment you really need all the code to control all variants of the hardware. Yes, it is not a good design. We know it, our customer knows it, but at the moment we have to live with the situation. And second, no one expects that you convert your driver source. Just write it from scratch Can you estimate what such a redesign would cost our customers? You would need several years to redesign the concept. cu, Marco - 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/
kbuild & C++
Hi, for one of our customers I have to port a Windows driver to Linux. Large parts of the driver's backend code consists of C++. How can I compile this code with kbuild? The C++ support (I have tested with 2.6.11) of kbuild seems to be incomplete / not working. cu, Marco Please send me a CC as e-mail. - 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/
kbuild C++
Hi, for one of our customers I have to port a Windows driver to Linux. Large parts of the driver's backend code consists of C++. How can I compile this code with kbuild? The C++ support (I have tested with 2.6.11) of kbuild seems to be incomplete / not working. cu, Marco Please send me a CC as e-mail. - 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/
Stripping in module
Hi, at the moment I am packaging a Linux module as an RPM archive. Therefor I would like to remove some of the not exported/needed symbols (like e.g. static functions or constants) from the Linux module. What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with "telos" from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko When I try to load such a module, insmod dies with a segmentation fault or the complete kernel dies (with "invalid operand: "). What is the reason for this problem? What is the correct way using kbuild to remove some symbols? cu, Marco - 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/
Stripping in module
Hi, at the moment I am packaging a Linux module as an RPM archive. Therefor I would like to remove some of the not exported/needed symbols (like e.g. static functions or constants) from the Linux module. What is the best way to do this with v2.6. I have tried e.g. to remove all symbols starting with telos from the module like this (after kbuild): strip -w -K '!telos*' -K 'telosi2c_usb_driver' telosi2c_linux.ko When I try to load such a module, insmod dies with a segmentation fault or the complete kernel dies (with invalid operand: ). What is the reason for this problem? What is the correct way using kbuild to remove some symbols? cu, Marco - 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/
