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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

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