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

[BlaisorBlade <blaisorblade_work@yahoo.it>]

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