Re: [kbuild-devel] sorting out the kerntypes mess
Hi Christoph The various dumping projects like lkcd and the s390 VM dump require debug information for the kernel, and they're using a mechanism that compiles a small file containing nothing but includes for interesting types into a Kerntypes file for the debugger. Unfortunately the various current ways to generate it are a little messy and thus we don't have support for it in mainline. As a clean way to implement it and supports multiple files that can be linked into Kerntypes (e.g. arch or subsystem-specific) I'd like to suggest the following additions to the kernel build system: kerntypes-y += object files KERNTYPEFLAGS += compile flags Which build all objects listed in kerntypes-y with the CFLAGS from KERNTYPEFLAGS (defaulting to CFLAGS) into a top-level Kerntypes file. First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. Unfortunately I'm a little lost in the current kbuild infrastructure so some help would be very welcome. If we can agree on something I will give it a try. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] make 'make help' show all *config targets and update descriptions slightly.
On Mon, Jan 24, 2005 at 10:05:48PM +0100, Jesper Juhl wrote: make help doesn't show make randconfig nor make config as options and the description of oldconfig could be better (IMHO). Patch below adds the missing targets to the help and updates the description of oldconfig. Applied - the help for oldconfig definitely got better. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] sorting out the kerntypes mess
On Sun, Jan 30, 2005 at 06:34:48PM +0100, Sam Ravnborg wrote: First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. Currenly it's called Kerntypes, which would make sense to be kept, but else yes. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. That could work aswell. Note that e.g. for s390 most of the additional bites are for drivers/s390/ datastructures which would make sense to be done with a drivers/s390/kerntypes.c file, but if it's really that bad let's go for your scheme. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
