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 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
