[uml-devel] [PATCH]Modules support in 2.6: reaching the complete fix

[uml-devel] [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

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

I've applied the various modules patches(i.e. apply_alternatives + some 
exports), have added some others, but still make modules complains: no 
unresolved symbols, but CRC are missing(at least with MODVERSIONS enabled; 
I'll try disabling it), and the kernel still panics(I guess that without 
MODVERSION this panic can't at all happen). I'm attaching the patch I built.

I've analized this, and got to the point that:

1) user_ksyms.c bundles a copy of the EXPORT_SYMBOL definition, but it's 
outdated; I've inserted the new one(with appropriate changes, i.e. 
s/CONFIG_/UML_CONFIG/) and it works. This is attached.

Still, the CRC are missing. The CRC symbol are defined, but we need also #2:

2) then, the UML build system is broken for USER_OBJS. The UML Makefiles 
define their own rule for such files. But the needed rule which would be 
needed is much more complex; this means that:
a) the terse output of 2.6 make doesn't appear(we have the complete command 
line)
b) a part of the post-processing needed for modules doesn't work.
Instead of specifying the rule each time, wouldn't it be good something 
such(in pseudo-code, I know there is only foreach in make-language)?

for i in USER_OBJS; do
  CFLAGS_$i+=USER_CFLAGS
done

If you accept, I volunteer to do it(i.e. find how to write this with make and 
do it).

3) When running the kernel, it panics this way:
Kernel panic: kernel BUG at kernel/module.c:1021!
The offending code is:

       if (!__find_symbol("struct_module", &owner, &crc, 1))
                BUG();
        return check_version(sechdrs, versindex, "struct_module", mod,
                             crc);

Though, this symbol is defined. Here the problem is probably that the link 
script is not up-to-date. I've given a look and verified this, but I didn't 
found THE actual error. And for this, I cannot help because I've not enough 
experience with link scripts(I've been able to learn the syntax, but I don't 
know the reason why some section missing in the i386 appear in the UML 
script; some are from libc, but I don't know which ones).

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

[-- Attachment #2: Module_support.patch --]
[-- Type: text/x-diff, Size: 3417 bytes --]

--- ./arch/um/kernel/mem.c.modfix	2003-12-02 17:20:43.000000000 +0100
+++ ./arch/um/kernel/mem.c	2003-12-12 18:56:29.000000000 +0100
@@ -119,6 +119,7 @@
 		kmem_top = CHOOSE_MODE(kmem_end_tt, kmem_end_skas);
 	return(kmem_top);
 }
+EXPORT_SYMBOL(get_kmem_end);
 
 #ifdef CONFIG_HIGHMEM
 /* Changed during early boot */
@@ -715,6 +716,7 @@
 
 	return(&mem_map[pfn - region->start_pfn]);
 }
+EXPORT_SYMBOL(pfn_to_page);
 
 unsigned long phys_to_pfn(unsigned long p)
 {
--- ./arch/um/kernel/user_syms.c.modfix	2003-12-02 17:20:43.000000000 +0100
+++ ./arch/um/kernel/user_syms.c	2003-12-13 12:05:17.000000000 +0100
@@ -16,6 +16,62 @@
  * since this includes various user-level headers.
  */
 
+/* Had to update this: this changed in late 2.5 to add CRC and other beasts
+ * and was never updated here- 13 Dec 2003-Blaisorblade*/
+
+/* v850 toolchain uses a `_' prefix for all user symbols */
+#ifndef MODULE_SYMBOL_PREFIX
+#define MODULE_SYMBOL_PREFIX ""
+#endif
+
+struct kernel_symbol
+{
+	unsigned long value;
+	const char *name;
+};
+
+#if !defined(UML_CONFIG_MODULES)
+#define EXPORT_SYMBOL(sym)
+#define EXPORT_SYMBOL_GPL(sym)
+#define EXPORT_SYMBOL_NOVERS(sym)
+
+#else /*UML_CONFIG_MODULES*/
+#ifndef __GENKSYMS__
+#ifdef UML_CONFIG_MODVERSIONS
+/* Mark the CRC weak since genksyms apparently decides not to
+ * generate a checksums for some symbols */
+#define __CRC_SYMBOL(sym, sec)					\
+	extern void *__crc_##sym __attribute__((weak));		\
+	static const unsigned long __kcrctab_##sym		\
+	__attribute__((section("__kcrctab" sec), unused))	\
+	= (unsigned long) &__crc_##sym;
+#else
+#define __CRC_SYMBOL(sym, sec)
+#endif
+
+/* For every exported symbol, place a struct in the __ksymtab section */
+#define __EXPORT_SYMBOL(sym, sec)				\
+	__CRC_SYMBOL(sym, sec)					\
+	static const char __kstrtab_##sym[]			\
+	__attribute__((section("__ksymtab_strings")))		\
+	= MODULE_SYMBOL_PREFIX #sym;                    	\
+	static const struct kernel_symbol __ksymtab_##sym	\
+	__attribute__((section("__ksymtab" sec), unused))	\
+	= { (unsigned long)&sym, __kstrtab_##sym }
+
+#define EXPORT_SYMBOL(sym)					\
+	__EXPORT_SYMBOL(sym, "")
+
+#define EXPORT_SYMBOL_GPL(sym)					\
+	__EXPORT_SYMBOL(sym, "_gpl")
+
+#endif
+
+/* We don't mangle the actual symbol anymore, so no need for
+ * special casing EXPORT_SYMBOL_NOVERS.  FIXME: Deprecated */
+#define EXPORT_SYMBOL_NOVERS(sym) EXPORT_SYMBOL(sym)
+#endif
+#if 0
 struct module_symbol
 {
 	unsigned long value;
@@ -57,6 +113,7 @@
 #define EXPORT_SYMBOL_NOVERS(var)  __EXPORT_SYMBOL(var, __MODULE_STRING(var))
 
 #endif
+#endif
 
 EXPORT_SYMBOL(__errno_location);
 
@@ -109,5 +166,7 @@
 
 EXPORT_SYMBOL(memset);
 EXPORT_SYMBOL(strstr);
+EXPORT_SYMBOL(printf);
+EXPORT_SYMBOL(strlen);
 
 EXPORT_SYMBOL(find_iomem);
--- ./include/asm-um/common.lds.S.modfix	2003-12-02 17:20:44.000000000 +0100
+++ ./include/asm-um/common.lds.S	2003-12-13 17:53:09.000000000 +0100
@@ -15,18 +15,6 @@
 
   RODATA
 
-  __start___ksymtab = .;	/* Kernel symbol table */
-  __ksymtab : { *(__ksymtab) }
-  __stop___ksymtab = .;
-
-  __start___gpl_ksymtab = .;	/* Kernel symbol table:	GPL-only symbols */
-  __gpl_ksymtab : { *(__gpl_ksymtab) }
-  __stop___gpl_ksymtab = .;
-
-  __start___kallsyms = .;       /* All kernel symbols */
-  __kallsyms : { *(__kallsyms) }
-  __stop___kallsyms = .;
-
   .unprotected : { *(.unprotected) }
   . = ALIGN(4096);
   PROVIDE (_unprotected_end = .);

[uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[Jeff Dike]

blaisorblade_spam@yahoo.it said:
> 1) user_ksyms.c bundles a copy of the EXPORT_SYMBOL definition, but
> it's  outdated; I've inserted the new one(with appropriate changes,
> i.e.  s/CONFIG_/UML_CONFIG/) and it works. This is attached. 

Yeah, this is nasty, but I couldn't think of any way of handling this without
just copying stuff.

> 2) then, the UML build system is broken for USER_OBJS.

This is separate from the module problem.  It still needs fixing though.

> Instead of specifying the rule each time, wouldn't it be good
> something  such(in pseudo-code, I know there is only foreach in
> make-language)?
>
> for i in USER_OBJS; do
>   CFLAGS_$i+=USER_CFLAGS done 

It would be nice just to have something in one Makefile, like arch/um/Makefile,
which makes this work.  I haven't looked at whether this is possible.

> And for this, I cannot help because I've not enough  experience with
> link scripts(I've been able to learn the syntax, but I don't  know the
> reason why some section missing in the i386 appear in the UML  script;
> some are from libc, but I don't know which ones).

The ones you deleted are all kernel sections.

				Jeff



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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

First, I tried without CONFIG_MODVERSIONS, and the panic doesn't happen(which 
was obvious, since the offending code is compiled #ifdef MODVERSIONS) and no 
other one appears. And the module loading works.

Only thing which obviously can't work is the umlgdb script; I need 2.6 Uml 
modules because I need to test a change to the 2.6 loop device(i.e. the 
partition support).

[About user_ksyms.c]
> Yeah, this is nasty, but I couldn't think of any way of handling this
> without just copying stuff.
Yes, I understand you've tried(though I don't know why user code can't include 
even some kernel headers, but that's my fault).

> > 2) then, the UML build system is broken for USER_OBJS.
>
> This is separate from the module problem.  It still needs fixing though.
Yes, but the general rule does some post-processing which is needed for 
modules. See scripts/Makefile.build:134 and following ones(around the 
"cmd_modversions" definition).

>
> It would be nice just to have something in one Makefile, like
> arch/um/Makefile, which makes this work.  I haven't looked at whether this
> is possible.
I'm going to try!

> > And for this, I cannot help because I've not enough  experience with
> > link scripts(I've been able to learn the syntax, but I don't  know the
> > reason why some section missing in the i386 appear in the UML  script;
> > some are from libc, but I don't know which ones).
>
> The ones you deleted are all kernel sections.

I understand this well(I'm aware of how are they born), but check and see that 
the RODATA macro, know, already includes them... so it's useless(if not 
harmful, but it shouldn't) to list them twice.

Bye
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux 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=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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

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

Alle 21:19, sabato 13 dicembre 2003, Jeff Dike ha scritto:

> > 2) then, the UML build system is broken for USER_OBJS.
>
> This is separate from the module problem.  It still needs fixing though.
>
> > Instead of specifying the rule each time, wouldn't it be good
> > something  such(in pseudo-code, I know there is only foreach in
> > make-language)?
> >
> > for i in USER_OBJS; do
> >   CFLAGS_$i+=USER_CFLAGS done
>
> It would be nice just to have something in one Makefile, like
> arch/um/Makefile, which makes this work.  I haven't looked at whether this
> is possible.

Aargh! I discovered how to write the above loop. BUT the problem is that 
setting CFLAGS_$i is not what we need, since that flags are added to kernel 
ones, while the kernel flags must be deleted.

So we must not do this, but instead add another rule to the main Makefiles, or 
something else patch them.
Do you need a different output(i.e. USERCC) for the USER_OBJS or it is not 
needed?

If not, I can just patch this way scripts/Makefile.lib:

c_flags         = $(if $(find $(@F),$(user-objs)), UML_user_c_flags, 
norm_c_flags)
#def. of norm_c_flags
#def. of UML_user_c_flags

In fact, the flags passed to the compiler are $(c_flags), which contain 
CFLAGS, EXTRA_CFLAGS, CFLAGS_$@ and the special, fixed kernel flags. So this 
instead is put inside norm_c_flags; 

Also, this can be moved to the main Makefile once for all (note these are 
deferred assignments):

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))
# You can put:
#  user-objs += whatever.o
# in each sub-Makefile.

I'm posting the "structure" patch for this(a bit different for various little 
details). If you agree with this, I'll go patching each needed Makefile.

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

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

--- ./arch/um/kernel/Makefile.user_obj	2003-12-02 17:20:43.000000000 +0100
+++ ./arch/um/kernel/Makefile	2003-12-17 18:42:37.000000000 +0100
@@ -26,7 +26,8 @@
 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
+	process.o tempfile.o time.o tty_log.o umid.o user_util.o user_syms.o \
+	frame.o
 USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file))
 
 DMODULES-$(CONFIG_MODULES) = -D__CONFIG_MODULES__
@@ -36,16 +37,16 @@
 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))
+CFLAGS_frame.o := $(patsubst -fomit-frame-pointer,,$(USER_CFLAGS)) -fno-omit-frame-pointer
 
 $(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 $@ $<
+## 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 $@ $<
 
 QUOTE = 'my $$config=`cat $(TOPDIR)/.config`; $$config =~ s/"/\\"/g ; $$config =~ s/\n/\\n"\n"/g ; while(<STDIN>) { $$_ =~ s/CONFIG/$$config/; print $$_ }'
 
--- ./arch/um/Makefile.user_obj	2003-12-13 18:36:36.000000000 +0100
+++ ./arch/um/Makefile	2003-12-17 18:46:34.000000000 +0100
@@ -129,6 +129,17 @@
 USER_CFLAGS := $(patsubst -D__KERNEL__,,$(USER_CFLAGS)) $(ARCH_INCLUDE) \
 	$(MODE_INCLUDE)
 
+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))
+
+#define __set_user_cflag
+# $(1)_cflags = $$(USER_CFLAGS)
+#endef
+#
+#define set_user_cflags
+# $(foreach f, $(user-objs), $(eval $(call __set_user_cflag, $(f))))
+#endef
+
 # To get a definition of F_SETSIG
 USER_CFLAGS += -D_GNU_SOURCE
 
--- ./scripts/Makefile.lib.user_obj	2003-10-01 21:25:17.000000000 +0200
+++ ./scripts/Makefile.lib	2003-12-17 18:33:19.000000000 +0100
@@ -136,8 +136,12 @@
 basename_flags = -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F)))
 modname_flags  = $(if $(filter 1,$(words $(modname))),-DKBUILD_MODNAME=$(subst $(comma),_,$(subst -,_,$(modname))))
 
+#For UML
+is_user_obj    = $(find $(@F),$(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 +169,12 @@
 __hostcxx_flags	=                              $(call flags,_hostcxx_flags)
 endif
 
-c_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
+kernelized_c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
 		 $(__c_flags) $(modkern_cflags) \
 		 $(basename_flags) $(modname_flags)
 
+c_flags 	= $(if $(is_user_obj), __c_flags, kernelized_c_flags)
+
 a_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
 		 $(__a_flags) $(modkern_aflags)
 

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[Jeff Dike]

blaisorblade_spam@yahoo.it said:
> If not, I can just patch this way scripts/Makefile.lib: 

This seems promising.  Can the new infrastructure be put in arch/um/Makefile?

This would isolate it nicely to UML since it's the only arch which needs it.

Although, thinking about this some more, this isn't the right way to do it
in the long run.  Ultimately, the userspace stuff will be confined to 
arch/um/os, along with the userspace CFLAGS.  So, the arch/um/os/Makefile
will contain this nonsense, and nothing outside there will have to worry
about it.

So, if you want to sign up to a longer project, you might start moving the
userspace stuff into arch/um/os-Linux instead of trying to fix the build.

				Jeff



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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

Alle 02:19, giovedì 18 dicembre 2003, Jeff Dike ha scritto:
> blaisorblade_spam@yahoo.it said:
> > If not, I can just patch this way scripts/Makefile.lib:
>
> This seems promising.  Can the new infrastructure be put in
> arch/um/Makefile?

I'm going to check... the variables are all set with = so it should work, but 
my problem is that it seems that the arch/um/Makefile is not included when it 
descends in sub-directories. However, even if it CAN be put there, I think 
this should NOT happen, and that it should be cleaned enough to be accepted 
in mainline. Why?
I think that it should have to be tuned for each release, and would not be 
likely to always be tunable(i.e. it could have to be re-engeneered if they 
change Makefile.lib enough). I don't use in fact an external interface of 
KBUILD, but I mingle inside its implementation(i.e. I violate encapsulation).

> This would isolate it nicely to UML since it's the only arch which needs
> it.

> Although, thinking about this some more, this isn't the right way to do it
> in the long run.  Ultimately, the userspace stuff will be confined to
> arch/um/os, along with the userspace CFLAGS.  So, the arch/um/os/Makefile
> will contain this nonsense, and nothing outside there will have to worry
> about it.

> So, if you want to sign up to a longer project, you might start moving the
> userspace stuff into arch/um/os-Linux instead of trying to fix the build.

I don't agree for "instead". I.e. I think that as the first thing this must be 
fixed, and then we will go hunting the bug for MODVERSIONS(it needs that we 
post-process userspace files).
After this, then I could do this user space change(I can't promise for now but 
I hope I'll be able); but it is a bit problematical because KBUILD isn't 
built to link objects from different directories.
Obviously I work for 2.6, not 2.4: clean-ups like this don't need duplicated 
effort. (And 2.6 is much more fun than 2.4, since it's all better).

Could symlink be accepted as a solution for this(i.e. a symlink from 
drivers/hostaudio_user.c to some file inside the os/ directory)?

In this case, the fix I'm writing is needed anyway and probably won't even 
need to be changed.

I'm now going to fix the various Makefiles and post the complete fix, since it 
it at least promising.

Bye
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux 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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[Jeff Dike]

On Thu, Dec 18, 2003 at 08:32:50PM +0100, BlaisorBlade wrote:
> I'm going to check... the variables are all set with = so it should work, but 
> my problem is that it seems that the arch/um/Makefile is not included when it 
> descends in sub-directories. 

Hummm, so all the state that's set up by the arch Makefile is made available
in environment variables to the subdir makes?  That's inconvenient.

> However, even if it CAN be put there, I think 
> this should NOT happen, and that it should be cleaned enough to be accepted 
> in mainline. Why?
> I think that it should have to be tuned for each release, and would not be 
> likely to always be tunable(i.e. it could have to be re-engeneered if they 
> change Makefile.lib enough). I don't use in fact an external interface of 
> KBUILD, but I mingle inside its implementation(i.e. I violate encapsulation).

It's UML-specific.  So, if at all possible, it should be in the UML tree,
not in the generic kbuild.

> I don't agree for "instead". I.e. I think that as the first thing this must be 
> fixed, and then we will go hunting the bug for MODVERSIONS(it needs that we 
> post-process userspace files).
> After this, then I could do this user space change(I can't promise for now but 
> I hope I'll be able); 

When the userspace stuff is all nicely hidden under arch/um/os, then whatever
fix you have for the build will apply only to that directory.  Maybe it will
turn out that it can't be hidden in the arch/um/os Makefile, but maybe it
can, and that's the right place to put it, if so.

> but it is a bit problematical because KBUILD isn't 
> built to link objects from different directories.

No one is proposing that.

> Could symlink be accepted as a solution for this(i.e. a symlink from 
> drivers/hostaudio_user.c to some file inside the os/ directory)?

If hostaudio is really Linux-specific, it should just be moved under 
arch/um/os-Linux/drivers along with tuntap and ethertap.

				Jeff


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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

Alle 23:13, giovedì 18 dicembre 2003, Jeff Dike ha scritto:
> On Thu, Dec 18, 2003 at 08:32:50PM +0100, BlaisorBlade wrote:
> > I'm going to check... the variables are all set with = so it should work,
> > but my problem is that it seems that the arch/um/Makefile is not included
> > when it descends in sub-directories.
>
> Hummm, so all the state that's set up by the arch Makefile is made
> available in environment variables to the subdir makes?  That's
> inconvenient.

No, I'm saying the opposite; I haven't had the time to check, but the issue 
I'm afraid of is that the variables I set in the arch/um/Makefile are not 
visible when used from scripts/Makefile.build(i.e. when descending in 
subdirs); in that case(i.e. they are not visible) the fix must go into 
scripts/Makefile.lib.
Note that it's only from a design point of view: I'll have to debug it more, 
since it stopped kernel compilation at the point of compiling 
scripts/empty.c(which is listed in "always").

> > However, even if it CAN be put there, I think
> > this should NOT happen, and that it should be cleaned enough to be
> > accepted in mainline. Why?
> > I think that it should have to be tuned for each release, and would not
> > be likely to always be tunable(i.e. it could have to be re-engeneered if
> > they change Makefile.lib enough). I don't use in fact an external
> > interface of KBUILD, but I mingle inside its implementation(i.e. I
> > violate encapsulation).
>
> It's UML-specific.  So, if at all possible, it should be in the UML tree,
> not in the generic kbuild.

I'll try, however I still think we should ask to kbuild developers.

To be clean, it must be on arch/um/Makefile for one reason(UML-specific) and 
scripts/Makefile.lib for another(information hiding-yes, OOP). But 
cleanlyness means "it can't break"; so actually scripts/Makefile.lib is 
cleaner IMHO. I'll provide both versions and you decide.

> > I don't agree for "instead". I.e. I think that as the first thing this
> > must be fixed, and then we will go hunting the bug for MODVERSIONS(it
> > needs that we post-process userspace files).
> > After this, then I could do this user space change(I can't promise for
> > now but I hope I'll be able);
>
> When the userspace stuff is all nicely hidden under arch/um/os, then
> whatever fix you have for the build will apply only to that directory.
Yes, I agree on this.
> Maybe it will turn out that it can't be hidden in the arch/um/os Makefile,
> but maybe it can, and that's the right place to put it, if so.
>
> > but it is a bit problematical because KBUILD isn't
> > built to link objects from different directories.
>
> No one is proposing that.
You didn't propose it, but it would be needed (see below).
>
> > Could symlink be accepted as a solution for this(i.e. a symlink from
> > drivers/hostaudio_user.c to some file inside the os/ directory)?
>
> If hostaudio is really Linux-specific, it should just be moved under
> arch/um/os-Linux/drivers along with tuntap and ethertap.

No, hostaudio is OSS-specific, and OSS is portable to many Unices. However I 
don't have experiences of Unices other than Linux.

But that one was just an example.

Let's say I have one module which has one kernel part and one user part(we 
have many examples of this), with a kernel part shared between different 
OS's. If the kernel part is inside drivers/ and the user part under 
os/<somewhere>, KBUILD won't work unless we:

1) horribly patch it (what I won't do obviously) to build a module from 
objects in different folders.

2) create a symlink from drivers/<filename> to os/<filename>. The symlink will 
be to os/, not to os-Linux or os-??, so this will work easily. Gcc would be 
called on drivers/<filename>

Bye
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux 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

Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix

[BlaisorBlade]

Alle 20:51, venerdì 19 dicembre 2003, BlaisorBlade ha scritto:
> > > I'm going to check... the variables are all set with = so it should
> > > work, but my problem is that it seems that the arch/um/Makefile is not
> > > included when it descends in sub-directories.
> >
> > Hummm, so all the state that's set up by the arch Makefile is made
> > available in environment variables to the subdir makes?  That's
> > inconvenient.
>
> No, I'm saying the opposite; I haven't had the time to check, but the issue
> I'm afraid of is that the variables I set in the arch/um/Makefile are not
> visible when used from scripts/Makefile.build(i.e. when descending in
> subdirs); in that case(i.e. they are not visible) the fix must go into
> scripts/Makefile.lib.

Now I've checked; what is used from arch/um/Makefile when recursing is only 
what it exports.

But that will be overriden by redefinition in each sub-make, if we speak about 
things as c_flags; also, it seems to me that I'll have to move even the lines 
about UML_USER_OBJS and UML_USER_SINGLE_OBJS so on(the new name I gave to 
USER_OBJS, to avoid conflicts) inside Makefile.lib;
what I can experiment is that when I export a variable, its content is 
expanded, even if it is a '=' variable rather than a ':=' var. I haven't 
found this inside make docs, so I may be wrong; but I've done a little test 
with the real Makefiles(details at request, this mail is just too long).

By the way: are you aiming to get an up-to-date UML into 2.6.1/.2?
I'm going to try shortly to get soon the patch reviewed by Kbuild developers, 
so that the patch is accepted by them, or they find a better way to handle 
this.

> Note that it's only from a design point of view: I'll have to debug it
> more, since it stopped kernel compilation at the point of compiling
> scripts/empty.c(which is listed in "always").
Fixed this, just a silly typo; now I've almost succeeded in compiling a whole 
UML kernel with this, and I'm going to put all my patches on the web.

The only problem is that there are some files not in UML ending in _user.c: 
i.e. fs/ext[23]/xattr_user.c, for now.
I'm trying to fix this, but it's not straightforward; my idea is using only 
files whose path starts with  arch/um, but it's not a 1 sec. fix, especially 
because I'm doing a lot of things at the very moment.
However, my patches can now be found at:

http://web.tiscali.it/no-redirect-tiscali/blaisorblade/linux/archives/UML/v1/index.html

They must be applied in order to the UML patch against the -test9 patch and 
the 2.6.0 kernel. They just fix Makefiles and module building. For now, 
disable extended attributes on ext2/ext3, since it triggers the build problem 
about xattr_user.c; use the align fix as needed. I've uploaded the files very 
quickly, so the files themself are ok(works for me), but nothing is ok in the 
"website".
(Sorry for the HTML index, but the hosting doesn't like a plain .htaccess, 
though they use Apache).

Bye
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux 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