linux-um archives
 help / color / mirror / Atom feed
From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Re: [PATCH]Modules support in 2.6: reaching the complete fix
Date: Tue, 23 Dec 2003 20:31:45 +0100	[thread overview]
Message-ID: <200312232031.45301.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <200312192051.32244.blaisorblade_spam@yahoo.it>

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

      reply	other threads:[~2003-12-23 19:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-13 17:28 [uml-devel] [PATCH]Modules support in 2.6: reaching the complete fix BlaisorBlade
2003-12-13 20:19 ` [uml-devel] " Jeff Dike
2003-12-14 15:04   ` BlaisorBlade
2003-12-17 17:51   ` BlaisorBlade
2003-12-18  1:19     ` Jeff Dike
2003-12-18 19:32       ` BlaisorBlade
2003-12-18 22:13         ` Jeff Dike
2003-12-19 19:51           ` BlaisorBlade
2003-12-23 19:31             ` BlaisorBlade [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200312232031.45301.blaisorblade_spam@yahoo.it \
    --to=blaisorblade_spam@yahoo.it \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox