3.7.1 (and linux-next): doesn't compile without CONFIG_ACPI
Hi, Is the following worth forwarding to the main list? It might be an artifact of my cross-compilation toolchain. Compilation without CONFIG_ACPI fails [1] because the headers include/acpi/* throw errors if included without CONFIG_ACPI. They are included unconditionally from two places: (1) acpi/acpi.h from iscsi_ibft.h from arch/x86/kernel/setup.c. The include of iscsi_ibft.h was harmless until an include of acpi/acpi.h was added to it in 4e639fdf0d0d745648aa62228ab8a0d9c03a563f (2) acpi/acpi_bus.h from pci-label.c, which used to only be compiled when ACPI was on, but that changed in 8a226e00eeed8db843d4a580013a49ae3559bcd7 to compile it even when only DMI and not ACPI is on. Putting CONFIG_ACPI guards around both includes lets the compilation proceed. [1] The errors are of this nature: include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH not defined ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why can not install kernel headers?
On 12/23/2012 12:01 PM, mobile.parmenides wrote: I am reading an article about kernel header installtion, its links as follows: http://lxr.linux.no/#linux+v2.6.32/Documentation/make/headers_install.txt#L11 Following a command given by the article: make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include the kernel headers should be installed into '/usr/include'. However, when checking '/usr/include/linux' and '/usr/include/asm', I found actually these kernel headers have not installed (by checking timestamps). In fact, kernel headers have be installed into 'include' subdirectory of kernel top-level directory. Obviously, the 'INSTALL_HDR_PATH' parameter in the above command does not take effect. Is there any way to deal with the problem? If I have to use 'cp' to install headers by hand, the 'INSTALL_HDR_PATH' seems not to play its roles. The following contradicts the examples in Documentation/make/headers_install.txt, but in my case (android tree), the make command creates an 'include' subdirectory in $INSTALL_HDR_PATH. That is, if I do make INSTALL_HDR_PATH=/path/to/headers/ headers_install Then, the headers are installed into /path/to/headers/include. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Link an out-of-tree module into vmlinux
Hello, Does the build system support building built-in components of vmlinux out-of-tree? That is, I know that these two are possible: (1) build out-of-tree code as a loadable kernel module (.ko) (use the M=/path/to/out-of-tree/dir) (2) build an in-tree module as a statically built-in component of vmlinux instead of as a LKM (use the CONFIG_module=y, or otherwise add the object files to obj-y instead of obj-m) The question is can you build an an _out-of-tree_ module as a statically built-in component of vmlinux? It seems you can't do it without modifying the root Makefile. That is, the reason (2) works is because the directory that will have built-in.o in it is in-tree and explicitly referenced by the root Makefile. I would hope that the M=dir parameter would effectively add the dir to the list, but it seems that it does not, spoiling the whole party: the built-in.o is correctly created, but it is not picked up by the vmlinux link-line. The only workaround I have working is to add an ugly out-of-tree path into the list of directories in the root Makefile. I could not find this use-case in the neither in the Kbuild documentation nor online. Thank you in advance. -alexei ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Link an out-of-tree module into vmlinux
Thank you for your reply. I am pursuing a slightly unusual goal: On 09/28/2012 02:01 PM, Dave Hylands wrote: On Fri, Sep 28, 2012 at 9:01 AM, Alexei Colin ale...@alexeicolin.com wrote: Does the build system support building built-in components of vmlinux out-of-tree? That is, I know that these two are possible: (1) build out-of-tree code as a loadable kernel module (.ko) (use the M=/path/to/out-of-tree/dir) (2) build an in-tree module as a statically built-in component of vmlinux instead of as a LKM (use the CONFIG_module=y, or otherwise add the object files to obj-y instead of obj-m) The question is can you build an an _out-of-tree_ module as a statically built-in component of vmlinux? You can build the entire kernel out-of-tree, and by that I mean have the object files go into a different tree than the source files. Yes, the O= usage is clear, and I do use it. It depends on what you mean by out-of-tree Sorry, by out-of-tree, I meant to refer to source code. For example, in (1) above, the module's *code* can be out-of-tree: it can live outside of the kernel source directory ($KDIR). The modules object files would go into same place as its source. You can't build the static portions separate from the rest of the kernel, i.e. all of the objects are in the same tree, either the source tree, or some other tree. In the case of out-of-tree modules, though, the objects do not have to go to the same tree where the rest of the objects go. They end up in the location specified by 'M='. That's were my inspiration comes from. In fact 'M=' and 'obj-y' bring me half way there: I get a built-in.o in the 'M=' location. All I need the next step to be: link 'vmlinux' as usual, except include the built-in.o from the 'M='. To clarify: can I statically link some code into the kernel, but keep this code (and its object files) in a directory that's not a descendant of KDIR? I can already accomplish this by editting root makefile and adding value of an MBUILTIN variable to vmlinux-dirs list, e.g. via core-y, then, do 'make M=my-out-of-tree-dir make MBUILTIN=my-out-of-tree-dir vmlinux'. But I hoped there's some already supported MBUILTIN-like var that does this in one step and without hacking the root makefile. I realize that this is strange and has implications on prerequisite checks -- introduces a strange dependency of vmlinux on something outside of KDIR, which doesn't happen for modules, of course, because vmlinux doesn't depend on them. But, this seems solvable by persisting what went into the vmlinux link and invalidating if that list changes. Thanks again. -alexei ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
