Re: [kbuild-devel] Needed help for UML kbuild.
[EMAIL PROTECTED] said:
some modules(i.e. hostaudio) are built from a userspace (needing the
special treatment) file and a kernel (to be compiled as usual)
file. How will kbuild link them together?
I have three workarounds:
- split the module into 2 separate ones, with the kernel one requiring the
other. BUT a lot of EXPORT_SYMBOLS should be added (one for each function
inside the userspace file at least)
- create a symlink from arch/um/drivers/hostaudio_user.c(old place) to
arch/um/os/drivers/hostaudio_user.c (new place) and pass the symlink to gcc.
This must be done only when the file will be part of a module.
Note that arch/um/os is a symlink to arch/um/os-{Linux, Win, any OS needed}.
- (worst option) make kbuild link together objects from different folders
inside one module. But I don't like this and I guess this would never be
accepted (this is against a fundamental kbuild assumption, IIRC).
Option 2 would work, although I would try to avoid that. I would rather
have everything under arch/um/os be userspace code, and none of it be kernel
code.
So, rather than have a module consisting of a userspace chunk and a kernel
chunk needing to be turned into a single .o, I would rather look at having
two modules, with the userspace piece plugging into an interface in the
kernel piece.
This is what I've envisioned for hostfs for a long time. You don't need to
stick host files underneath hostfs files - you can stick other host resources
under them, and the way to do that is to have multiple hostfs userspace modules
which plug into an interface in the hostfs kernel piece, each of which provides
access to a different sort of host resource.
So, I would look at the other problematic modules and see if they can be treated
in the same way.
So, I basically don't like the idea of making the CFLAGS munging part of kbuild
overall. It's very UML-specific now, and in the future, it will become specific
to small pieces of UML.
Jeff
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] UML kbuild patch
The UML build needs a few kbuild changes in order to work with the latest stuff. Since kbuild now enforces the use of the linker script on the vmlinux build, UML can't use its old two-stage link, where vmlinux is a normal relocatable object file which is linked into the linux binary with the linker script So, in order to fold those into one stage and produce an ELF binary, I need the vmlinux linker to actually be gcc. This implies I need a -Wl,-T,arch/$(ARCH)/vmlinux.lds.s instead of the usual -T arch/$(ARCH)/vmlinux.lds.s. This is done without breaking the other arches by changing the final link command to $(LD_vmlinux) which is defaulted to $(LD) if the arch doesn't define it. The -Wl,... is done similarly by using $(LDFLAGS_vmlinux_default) if the linker command is anything but gcc and $(LDFLAGS_vmlinux_gcc) if it is gcc. The one caveat is that I removed $(LDFLAGS) from the link line - you might want to add it back. You can pull bk://jdike.stearns.org/kbuild-2.5. The patch is also appended. Jeff # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet1.600 - 1.602 # Makefile1.305 - 1.307 # # The following is the BitKeeper ChangeSet Log # # 02/09/23 [EMAIL PROTECTED]1.601 # Fixes to allow UML to build with the new vmlinux rules. # # 02/09/23 [EMAIL PROTECTED]1.602 # Made the UML Makefile changes work for the other arches. # # diff -Nru a/Makefile b/Makefile --- a/Makefile Mon Sep 23 19:50:33 2002 +++ b/Makefile Mon Sep 23 19:50:33 2002 @@ -288,10 +288,12 @@ # we cannot yet know if we will need to relink vmlinux. # So we descend into init/ inside the rule for vmlinux again. +LD_vmlinux := $(if $(LD_vmlinux),$(LD_vmlinux),$(LD)) + vmlinux-objs := $(HEAD) $(INIT) $(CORE_FILES) $(LIBS) $(DRIVERS) $(NETWORKS) quiet_cmd_link_vmlinux = LD $@ -cmd_link_vmlinux = $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ +cmd_link_vmlinux = $(LD_vmlinux) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ --start-group \ $(CORE_FILES) \ $(LIBS) \ @@ -313,7 +315,11 @@ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map endef -LDFLAGS_vmlinux += -T arch/$(ARCH)/vmlinux.lds.s +LDFLAGS_vmlinux_default = -T arch/$(ARCH)/vmlinux.lds.s +LDFLAGS_vmlinux_gcc = -Wl,-T,arch/$(ARCH)/vmlinux.lds.s + +vmlinux_base = $(basename $(notdir $(LD_vmlinux))) +LDFLAGS_vmlinux += $(if +$(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_default)) vmlinux: $(vmlinux-objs) arch/$(ARCH)/vmlinux.lds.s FORCE $(call if_changed_rule,link_vmlinux) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: UML kbuild patch
[EMAIL PROTECTED] said: The actual executable UML generates is called linux anyway, so its Makefile can have its own rule (as for other archs the boot images) which builds linux from vmlinux using gcc and the link script. - I.e. the same way as UML used to do it earlier, anyway. I'd actually prefer the one-stage link. That takes better advantage of the infrastructure that you've put in place. Instead of making LDFLAGS_vmlinux available to the arch Makefile, can you make cmd_link_vmlinux available? Then I can just rewrite it. That looks like it has no impact on the global Makefile except for moving it above the include of the arch Makefile. Jeff --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
