[uml-devel] Needed help for UML kbuild.

[uml-devel] Needed help for UML kbuild.

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

I'm a UML(User mode linux, the arch/um folder in 2.5/2.6) developer, and I 
need some support to update its build system to the 2.6 changes.

The problem is that since that port of Linux runs as a normal process and 
emulates a whole box, some of its source files must be compiled against 
user-space headers and without some flags; this cannot be handled simply by 
setting CFLAGS_<target name>, as the problematic flags are added by 
scripts/Makefile.lib itself; so I've prepared a patch(that I attached) which 
recognizes these objects to compile them properly. This patch will need to go 
in stock 2.6 and mustn't interfere with the rest of the kernel compilation, 
so I especially want to hear from you.

The "stuff" part of it will be sent to the UML developers; it's just changing 
the Uml makefiles to use the new way of working.

The "main" must be reviewed here, especially for the scripts/Makefile.lib; the 
Makefile.build change is just cosmetic(changing the shown tag; I must change 
it more to fix the filename alignment; but why don't you use a tab for 
this?). The Makefile.lib, instead, is the core change: objects listed in 
UML_USER_OBJS get completely different CFLAGS.
The list always contains, in the arch/um subfolders, all objects whose name 
matches %_user.o(as it has always been for UML).

A strange(not documented) issue I met with GNU make 3.80 is that when I export 
a recursively expanded variable, what goes to the sub-make is the expanded 
value, not the "formula definition".

Bye and thanks for your attention.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN

[-- Attachment #2: Main_A-04-User_obj_makefiles.patch --]
[-- Type: text/x-diff, Size: 4163 bytes --]

--- ./arch/um/Makefile.user_obj	2003-12-13 18:36:36.000000000 +0100
+++ ./arch/um/Makefile	2003-12-24 18:18:22.000000000 +0100
@@ -13,10 +13,6 @@
 # EXTRAVERSION...
 MODLIB := $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
 
-ifeq ($(CONFIG_DEBUG_INFO),y)
-CFLAGS := $(subst -fomit-frame-pointer,,$(CFLAGS))
-endif
-
 core-y			+= $(ARCH_DIR)/kernel/		 \
 			   $(ARCH_DIR)/drivers/          \
 			   $(ARCH_DIR)/sys-$(SUBARCH)/
@@ -129,13 +125,18 @@
 USER_CFLAGS := $(patsubst -D__KERNEL__,,$(USER_CFLAGS)) $(ARCH_INCLUDE) \
 	$(MODE_INCLUDE)
 
-# To get a definition of F_SETSIG
-USER_CFLAGS += -D_GNU_SOURCE
+#From main Makefile, these options are set after including the ARCH makefile.
+#So copy them here.
+ifndef CONFIG_FRAME_POINTER
+USER_CFLAGS		+= -fomit-frame-pointer
+endif
 
 ifdef CONFIG_DEBUG_INFO
-USER_CFLAGS += -g
+USER_CFLAGS		+= -g
 endif
 
+# To get a definition of F_SETSIG
+USER_CFLAGS += -D_GNU_SOURCE
 
 CLEAN_FILES += linux x.i gmon.out $(ARCH_DIR)/uml.lds.s \
 	$(ARCH_DIR)/dyn_link.ld.s $(ARCH_DIR)/include/uml-config.h \
--- ./fs/hostfs/Makefile.user_obj	2003-12-19 18:40:23.000000000 +0100
+++ ./fs/hostfs/Makefile	2003-12-24 16:47:25.000000000 +0100
@@ -15,15 +15,10 @@
 obj-y = 
 obj-$(CONFIG_HOSTFS) += hostfs.o
 
-SINGLE_OBJS = $(foreach f,$(patsubst %.o,%,$(obj-y) $(obj-m)),$($(f)-objs))
+# Here we aren't in arch/um, so list explicitly files.
+UML_USER_OBJS := hostfs_user.o
 
-USER_OBJS := $(filter %_user.o,$(obj-y) $(obj-m) $(SINGLE_OBJS))
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
-
-USER_CFLAGS += -DSTAT64_INO_FIELD=$(STAT64_INO_FIELD)
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+CFLAGS_hostfs_user.o += -DSTAT64_INO_FIELD=$(STAT64_INO_FIELD)
 
 clean:
 
--- ./scripts/Makefile.lib.user_obj	2003-10-01 21:25:17.000000000 +0200
+++ ./scripts/Makefile.lib	2003-12-24 16:39:18.000000000 +0100
@@ -136,8 +136,22 @@
 basename_flags = -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F)))
 modname_flags  = $(if $(filter 1,$(words $(modname))),-DKBUILD_MODNAME=$(subst $(comma),_,$(subst -,_,$(modname))))
 
+#For UML
+
+#UML_USER_OBJS += $(foreach i,$(_UML_USER_OBJS),$(filter-out $(subst arch/um,,$(i)),$(i)))
+#UML_USER_OBJS += $(_UML_USER_OBJS)
+
+#With filter-out we add only files if dir is not changed by subst, i.e. is not in arch/um
+
+_UML_USER_OBJS = $(filter %_user.o,$(obj-y) $(obj-m) $(multi-objs))
+UML_USER_OBJS += $(if $(filter-out $(subst arch/um,,$(obj)),$(obj)),\
+			$(_UML_USER_OBJS))
+
+is_user_obj    = $(findstring $(@F),$(UML_USER_OBJS))
+
+_c_flags       = $(if $(is_user_obj),$(USER_CFLAGS),$(CFLAGS) $(EXTRA_CFLAGS)) \
+  		 $(CFLAGS_$(*F).o)
 
-_c_flags       = $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F).o)
 _a_flags       = $(AFLAGS) $(EXTRA_AFLAGS) $(AFLAGS_$(*F).o)
 _hostc_flags   = $(HOSTCFLAGS)   $(HOST_EXTRACFLAGS)   $(HOSTCFLAGS_$(*F).o)
 _hostcxx_flags = $(HOSTCXXFLAGS) $(HOST_EXTRACXXFLAGS) $(HOSTCXXFLAGS_$(*F).o)
@@ -165,10 +179,17 @@
 __hostcxx_flags	=                              $(call flags,_hostcxx_flags)
 endif
 
-c_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
+__kernel_c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
 		 $(__c_flags) $(modkern_cflags) \
 		 $(basename_flags) $(modname_flags)
 
+#We must strip the NOSTDINC and -D__KERNEL__ (else we mess up /usr/include/asm/*)
+#and can strip the -DKBUILD... stuff and the -DMODULE, as we don't include
+#linux headers.
+__umUser_c_flags = -Wp,-MD,$(depfile) $(__c_flags)
+
+c_flags 	= $(if $(is_user_obj), $(__umUser_c_flags), $(__kernel_c_flags))
+
 a_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
 		 $(__a_flags) $(modkern_aflags)
 
--- ./scripts/Makefile.build.user_obj	2003-10-10 16:09:28.000000000 +0200
+++ ./scripts/Makefile.build	2003-12-23 17:22:07.000000000 +0100
@@ -125,7 +125,7 @@
 # The C file is compiled and updated dependency information is generated.
 # (See cmd_cc_o_c + relevant part of rule_cc_o_c)
 
-quiet_cmd_cc_o_c = CC $(quiet_modtag)  $@
+quiet_cmd_cc_o_c = $(if $(is_user_obj),USR-)CC $(quiet_modtag)  $@
 
 ifndef CONFIG_MODVERSIONS
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<

[-- Attachment #3: Stuff_A-04-User_obj_makefiles.patch --]
[-- Type: text/x-diff, Size: 6462 bytes --]

--- ./arch/um/drivers/Makefile.user_obj	2003-12-19 18:40:22.000000000 +0100
+++ ./arch/um/drivers/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -44,14 +44,7 @@
 
 obj-y += stdio_console.o $(CHAN_OBJS)
 
-USER_SINGLE_OBJS = $(foreach f,$(patsubst %.o,%,$(obj-y) $(obj-m)),$($(f)-objs))
-
-USER_OBJS := $(filter %_user.o,$(obj-y) $(obj-m) $(USER_SINGLE_OBJS)) fd.o \
-	null.o pty.o tty.o xterm.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+UML_USER_OBJS += fd.o null.o pty.o tty.o xterm.o
 
 clean:
 
--- ./arch/um/kernel/skas/sys-i386/Makefile.user_obj	2003-04-17 16:11:40.000000000 +0200
+++ ./arch/um/kernel/skas/sys-i386/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -5,10 +5,6 @@
 
 obj-y = sigcontext.o
 
-USER_OBJS = sigcontext.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+UML_USER_OBJS += sigcontext.o
 
 clean :
--- ./arch/um/kernel/skas/Makefile.user_obj	2003-12-19 18:40:22.000000000 +0100
+++ ./arch/um/kernel/skas/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -10,8 +10,7 @@
 host-progs	:= util/mk_ptregs
 clean-files	:= include/skas_ptregs.h
 
-USER_OBJS = $(filter %_user.o,$(obj-y)) process.o time.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
+UML_USER_OBJS += process.o time.o
 
 $(TOPDIR)/arch/um/include/skas_ptregs.h : $(src)/util/mk_ptregs
 	@echo -n '  Generating $@'
@@ -23,6 +22,3 @@
 		echo ' (updated)'; \
 		mv -f $@.tmp $@; \
 	fi
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
--- ./arch/um/kernel/tt/ptproxy/Makefile.user_obj	2003-04-17 16:11:41.000000000 +0200
+++ ./arch/um/kernel/tt/ptproxy/Makefile	2003-12-24 18:10:10.000000000 +0100
@@ -5,9 +5,6 @@
 
 obj-y = proxy.o ptrace.o sysdep.o wait.o
 
-USER_OBJS := $(foreach file,$(obj-y),$(src)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+UML_USER_OBJS := $(obj-y)
 
 clean:
--- ./arch/um/kernel/tt/sys-i386/Makefile.user_obj	2003-04-17 16:11:41.000000000 +0200
+++ ./arch/um/kernel/tt/sys-i386/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -5,10 +5,6 @@
 
 obj-y = sigcontext.o
 
-USER_OBJS = sigcontext.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+UML_USER_OBJS += sigcontext.o
 
 clean :
--- ./arch/um/kernel/tt/Makefile.user_obj	2003-08-31 15:51:39.000000000 +0200
+++ ./arch/um/kernel/tt/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -11,17 +11,11 @@
 
 obj-$(CONFIG_PT_PROXY) += gdb_kern.o ptproxy/
 
-USER_OBJS := $(filter %_user.o,$(obj-y)) gdb.o time.o tracer.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
+UML_USER_OBJS += gdb.o time.o tracer.o
 
 UNMAP_CFLAGS := $(patsubst -pg -DPROFILING,,$(USER_CFLAGS))
 UNMAP_CFLAGS := $(patsubst -fprofile-arcs -ftest-coverage,,$(UNMAP_CFLAGS))
 
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
-
-$(O_TARGET) : $(obj)/unmap_fin.o
-
 $(obj)/unmap.o: $(src)/unmap.c
 	$(CC) $(UNMAP_CFLAGS) -c -o $@ $<
 
--- ./arch/um/kernel/Makefile.user_obj	2003-12-02 17:20:43.000000000 +0100
+++ ./arch/um/kernel/Makefile	2003-12-23 17:28:25.000000000 +0100
@@ -25,35 +25,28 @@
 
 user-objs-$(CONFIG_TTY_LOG) += tty_log.o
 
-USER_OBJS := $(filter %_user.o,$(obj-y))  $(user-objs-y) config.o helper.o \
-	process.o tempfile.o time.o tty_log.o umid.o user_util.o user_syms.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
+UML_USER_OBJS += $(user-objs-y) config.o helper.o \
+	process.o tempfile.o time.o tty_log.o umid.o user_util.o user_syms.o \
+	frame.o
 
 DMODULES-$(CONFIG_MODULES) = -D__CONFIG_MODULES__
 DMODVERSIONS-$(CONFIG_MODVERSIONS) = -D__CONFIG_MODVERSIONS__
 
-
 CFLAGS_user_syms.o = -D__AUTOCONF_INCLUDED__ $(DMODULES-y) $(DMODVERSIONS-y) \
 	-I/usr/include -I../include
 
-CFLAGS_frame.o := $(patsubst -fomit-frame-pointer,,$(USER_CFLAGS))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
-
 # This has to be separate because it needs be compiled with frame pointers
 # regardless of how the rest of the kernel is built.
 
-$(obj)/frame.o: $(src)/frame.c
-	$(CC) $(CFLAGS_$(notdir $@)) -c -o $@ $<
+#$(obj)/frame.o: $(src)/frame.c
+#	$(CC) $(CFLAGS_$(notdir $@)) -c -o $@ $<
+CFLAGS_frame.o := -fno-omit-frame-pointer
 
 QUOTE = 'my $$config=`cat $(TOPDIR)/.config`; $$config =~ s/"/\\"/g ; $$config =~ s/\n/\\n"\n"/g ; while(<STDIN>) { $$_ =~ s/CONFIG/$$config/; print $$_ }'
 
 $(obj)/config.c : $(src)/config.c.in $(TOPDIR)/.config
 	$(PERL) -e $(QUOTE) < $(src)/config.c.in > $@
 
-$(obj)/config.o : $(obj)/config.c
-
 modules:
 
 fastdep:
--- ./arch/um/os-Linux/drivers/Makefile.user_obj	2003-04-17 16:11:41.000000000 +0200
+++ ./arch/um/os-Linux/drivers/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -9,11 +9,3 @@
 obj-y = 
 obj-$(CONFIG_UML_NET_ETHERTAP) += ethertap.o
 obj-$(CONFIG_UML_NET_TUNTAP) += tuntap.o
-
-USER_SINGLE_OBJS = $(foreach f,$(patsubst %.o,%,$(obj-y)),$($(f)-objs))
-
-USER_OBJS = $(filter %_user.o,$(obj-y) $(USER_SINGLE_OBJS))
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
--- ./arch/um/os-Linux/Makefile.user_obj	2003-04-17 16:11:41.000000000 +0200
+++ ./arch/um/os-Linux/Makefile	2003-12-23 18:16:11.000000000 +0100
@@ -5,10 +5,7 @@
 
 obj-y = file.o process.o tty.o drivers/
 
-USER_OBJS := $(foreach file,file.o process.o tty.o,$(obj)/$(file))
-
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
+UML_USER_OBJS += file.o process.o tty.o
 
 clean :
 
--- ./arch/um/sys-i386/Makefile.user_obj	2003-12-19 18:40:23.000000000 +0100
+++ ./arch/um/sys-i386/Makefile	2003-12-23 13:14:37.000000000 +0100
@@ -4,8 +4,7 @@
 obj-$(CONFIG_HIGHMEM) += highmem.o
 obj-$(CONFIG_MODULES) += module.o
 
-USER_OBJS := bugs.o ptrace_user.o sigcontext.o fault.o
-USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
+UML_USER_OBJS += bugs.o sigcontext.o fault.o
 
 SYMLINKS = semaphore.c highmem.c module.c
 SYMLINKS := $(foreach f,$(SYMLINKS),$(src)/$f)
@@ -21,9 +20,6 @@
 	ln -sf $(TOPDIR)/arch/i386/$($(notdir $1)-dir)/$(notdir $1) $1
 endef
 
-$(USER_OBJS) : %.o: %.c
-	$(CC) $(CFLAGS_$(notdir $@)) $(USER_CFLAGS) -c -o $@ $<
-
 $(SYMLINKS): 
 	$(call make_link,$@)
 

[uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[Christoph Hellwig]

On Wed, Dec 24, 2003 at 08:19:23PM +0100, BlaisorBlade wrote:
> Makefile.build change is just cosmetic(changing the shown tag; I must change 
> it more to fix the filename alignment; but why don't you use a tab for 
> this?). The Makefile.lib, instead, is the core change: objects listed in 
> UML_USER_OBJS get completely different CFLAGS.

Please don't use shouting names..

> The list always contains, in the arch/um subfolders, all objects whose name 
> matches %_user.o(as it has always been for UML).

This doesn't sound like a good heuristic, imagine a driver using e.g.
foo_user.c for the chardev user interface.  In general I'd suggest adding
parallel infrastructure for user-$(CONFIG_FOO) variables in addition to
the current obj-* and host-*.  The only problem you could get with that
is that you need to take special care of the link order.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[BlaisorBlade]

Alle 11:45, giovedì 25 dicembre 2003, Christoph Hellwig ha scritto:

> Please don't use shouting names..

Ok. Then user-objs; or if this could be used somewhere else, uml-user-objs.

> > The list always contains, in the arch/um subfolders, all objects whose
> > name matches %_user.o(as it has always been for UML).
>
> This doesn't sound like a good heuristic, imagine a driver using e.g.
> foo_user.c for the chardev user interface.

UML 2.4 has been written with this in mind. If an UML file is named *_user.c, 
that already means that it needs special treatment. Everywhere inside 
arch/um.
So the heuristic does work, for UML (and only for UML). Really.

> In general I'd suggest adding
> parallel infrastructure for user-$(CONFIG_FOO) variables in addition to
> the current obj-* and host-*.  The only problem you could get with that
> is that you need to take special care of the link order.

In general you are right. But the current content of the average UML Makefile 
is like this:

<setting obj-y and obj-m the normal way>

<1:> USER_SINGLE_OBJS = $(foreach f,$(patsubst %.o,%,$(obj-y) 
$(obj-m)),$($(f)-objs))

<2:> USER_OBJS = $(filter %_user.o,$(obj-y) $(obj-m) $(USER_SINGLE_OBJS)) fd.o 
\
        null.o pty.o tty.o xterm.o

<3:> $(USER_OBJS) : %.o: %.c
        $(CC) $(CFLAGS_$@) $(USER_CFLAGS) -c -o $@ $<

And this content is repeated for each single Makefile.

That becomes, with the API I suggest:

<setting obj-y and obj-m as always>
user-objs +=  fd.o null.o pty.o tty.o xterm.o

But if you don't like that heuristic, this means that <1:> and <2:> remain 
repeated in each Makefile, while only <3:> can be removed.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[BlaisorBlade]

Alle 21:21, martedì 6 gennaio 2004, hai scritto:
> > I'm posting this as reminder... however the UML naintainer said that the
> > special treatment (which remains the same) must happens for a different
> > file set, i.e. all the files below one folder.
>
> Thanks - and it was needed.
> I have shifted mailer since the first mail.
> Can you please send the patch once more.

Ok, I'm sending them privately to you.
If you want to actually compile UML(the code in mainline is outdated) to debug 
the Makefiles, here is a patch to apply onto vanilla 2.6.0 to get a working 
UML:

http://web.tiscali.it/no-redirect-tiscali/blaisorblade/linux/archives/UML/v8/00-Combo-v8.bz2

In that patch, there is a lot of stuff including *this* patch. If you need to 
back it out, you can find it as H-Makefiles/H-02-User_obj_makefiles.patch(but 
to unapply it you must unapply first H-04, then H-03 and finally H-02).

The "main" patch is the core infrastructure, while the "stuff" one is the 
patch for all Makefiles under arch/um to use the new scheme.

However, this patch is built using the idea of selecting *_user.c + the files 
which are explicitly asked. Note that this is what is currently implemented 
inside UML; the current version is however unclean and broken (since it 
doesn't use the kbuild, it doesn't either do the post-process stage for 
modversions).

> Also, can you point me to a directory where the different CFLAGS are
> needed. Just to let me browse through what is present in the kernel src
> today.
Currently there is not a single directory, but a set of files. See for 
instance arch/um/drivers/*_user.c. 

A clearer rationale: If something inside the UML must, i.e., write to a 
console, UML must send the request to the host device corresponding to that 
console(an xterm in most cases). So, we have some code which interacts with 
the tty layer on the kernel side(xterm_kern.c in that folder), and then 
another file (xterm.c in the some folder) which is the userspace part that 
runs on the host, and that will link against the host's userspace header and 
libc code.

Libc isn't an issue here, but gcc must search /usr/include and not 
<linuxTree>/include for include files.

Then, the UML maintainer (Jeff Dike) pointed out that as a further cleanup, he 
wants to move the *_user.c in arch/um/os-Linux, since when UML is compiled to 
run onto another OS as host system (that will happen, a separate port onto 
Win32 exists) a different version of those files will probably be needed. So 
a separate Makefile could be used.

I agree about moving the files, indeed, BUT there is a problem for modules:

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).

The idea I currently prefer is the second one, even if the implementation can 
be a little more intrusive. The UML maintainer was of the idea of a separate 
Makefile, but I've not yet got an answer about the module issue.

> What I have in mind may be a specific Makefile.uml instead.
> We did that for klibc with success.
>
> [See klic.bkbits.net]
I've given a quick look, but that seems a bit too much unrelated (i.e. that 
doesn't link with the kernel!). However doing a separate Makefile can be ok, 
if that doesn't go changing c_flags or such variables from Makefile.lib 
(which would be fragile).

Bye and thanks for interest!
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[Jeff Dike]

blaisorblade_work@yahoo.it 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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[BlaisorBlade]

Alle 01:19, giovedì 8 gennaio 2004, Jeff Dike ha scritto:
> blaisorblade_work@yahoo.it 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)

> 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.

No idea about this hostfs feature - apart the fact it can be something good to 
have (I don't yet see samples but this can be my fault; if you have any 
specific one I'd like it). However, I don't think this is needed for all 
modules. However, this can be delayed to after (or at least, I'd like to 
implement it, after having some other "host resource" to manage). For now, I 
would split the modules into two parts and add needed EXPORT_SYMBOL's. It's 
worth noting that while in 2.4 a module exports all symbols, in 2.6 symbols 
must be exported explicitly.

**So: would you merge this patch?**
If yes, can I be smart about files to just move? (Shipping a list of mv 
commands would be ok?)
Also, the *_user.c (+ the other user-objs) should go under under 
os-Linux/{drivers, kernel, kernel/tt, kernel/skas} ..., right?

The other modules I found in UML 2.6, for which I don't see an obvious reason 
to use a "register_xxx" thing, are:
-hostaudio
-the watchdogs (what are they?)
-hppfs
-cow (but why tristate? Maybe related to the standalone cow device, that I 
have not understood).
-Example IO memory driver.

-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: [kbuild-devel] Needed help for UML kbuild.

[Jeff Dike]

blaisorblade_work@yahoo.it said:
> **So: would you merge this patch?** 
> If yes, can I be smart about files
> to just move? (Shipping a list of mv  commands would be ok?) Also, the
> *_user.c (+ the other user-objs) should go under under  os-Linux/
> {drivers, kernel, kernel/tt, kernel/skas} ..., right? 

I'd rather you look at the actual libc dependencies in the _user files and
add interfaces to os that let those dependencies be moved.  Then merge the
remaining code (which should be independent of both libc and kernel) into
the corresponding _kern files.  I want as little as possible under os.

> -the watchdogs (what are they?)

They watch the system and reboot it if it appears to hang.

> -cow (but why tristate? Maybe related to the standalone cow device, that I 
> have not understood).

Yeah, when I get the cow driver working, it makes sense for it to be modular.

				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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel