linux-um archives
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade_spam@yahoo.it>
To: Chris Wedgwood <cw@f00f.org>, LKML <linux-kernel@vger.kernel.org>,
	user-mode-linux-devel@lists.sourceforge.net
Cc: Andrew Morton <akpm@osdl.org>, Jeff Dike <jdike@addtoit.com>
Subject: [uml-devel] Why UML often does not build (was: Re: [PATCH] UML: Build fix for TT w/o SKAS)
Date: Thu, 28 Oct 2004 22:54:21 +0200	[thread overview]
Message-ID: <200410282254.21944.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <20041028193329.GF851@taniwha.stupidest.org>

On Thursday 28 October 2004 21:33, Chris Wedgwood wrote:
> On Thu, Oct 28, 2004 at 09:04:30PM +0200, Blaisorblade wrote:
> > Hmm, this is true for some of them, not for other ones (mostly
> > fixups, but some wrong).

> ive been sending patches out for ages and they are getting nowhere.
"Not getting an answer" does not mean "getting nowhere". I'm not absolutely 
able, for instance, to understand the update for generic IRQs. I've seen the 
"compile only" fixes from Jeff. And they were "compile-only". But 
understanding the other changes from you is too difficult for me.

About Jeff, I still keep CC'ing him every time, but as he has admitted 
privately, he does not have the time to answer detailedly to each patch. 
Since I'm here from some time, I'm now using my own judgement on some little 
things (i.e. little compile-only fixes, or when a patch is being rejected for 
questionable reasons, or when it is reportedly safe).

I don't try to touch the real UML core without getting a review from Jeff, and 
anyone having a clue on what I'm doing is welcome.

> if people have better fixes, these have been weeks (in some cases
> months) to get them in

For instance, Jeff rejected the mconsole-proc rewrite. So, I tried harder, 
then updated the patch to just #ifdef out his version, and was going to send 
it in.

However, you are not entirely wrong. Jeff does not scale enough to the rate of 
kernel changes, and not even I can (I'm only a 1st year university student; 
luckily they have not yet started teaching anything new).

> > However, always CC both the -devel list (my request) and the LKML
> > (Andrew's request to me some time ago) when sending UML patches.

> i admit i've missed -devel most of the time,  i said ill do that from
> now on

> the fact remains, people have fixes that are weeks old or more and if
> you dont submit them to get them merged, then please let another
> potential suitable fix go in for now

> UML often doesn't build and less often runs correctly --- it probably
> one of the worst architectures for this in a sense (i don't know about
> the obscure stuff, i bet those break too --- but nobody uses them
> which isn't the case for UML)

Well, this is true. There are mainly these reasons:

1) the Linux Kernel often breaks when using certain GCC versions or certain 
binutils, and has to be fixed.

But UML is a binary doing the most unusual things on the world around, so it 
must cope also with different versions of libc / binutils / host kernel.

2) Uml is often not cared by mainline developers. It was merged in 2.6.9 and 
remained unworking for ages just because Linus ignored UML patches for ages. 
And right now, if UML does not compile it's for the Ingo Molnar's hardirq 
patch and for a missed silly prototype change for a TTY api change (they 
fixed the UML user, ended up changing one UML function prototype, forgot to 
do a trivial update to one user. One missed "grep" invocation, in fact).

3) Uml *is* strange. The kernel has his own linking script? Uml must have a 
merged version of the userspace one from binutils and of the kernel one.

Since it must remap its .text section away under his back, it has to copy the 
kernel image and remap the data with one one-shot function, which is 
statically linked - so you end up with symbol clashes on some glibc using 
NPTL, for trivial reasons - and so on.

4) We are too few. The currently active developers (and I mean only the one 
which this month have being working on it) are:

- Bodo Stroesser - he came in just now, but he's doing a tremendous work on 
getting SYSEMU working well.

- you, Chris

- Gerd Knorr, the Suse UML packager and maintainer.

- I and Jeff, for various other stuff.

The number nearly doubles if you just include work done before this summer, 
with Henrik Normstrod, M.A. Young and Ingo Molnar coming here. But that's the 
fact.

I.e., if after 2.6.9-rc4 for any reason I did not send the fixes (like being 
overloaded or away from the net), Jeff probably would have sent them (he was 
just about doing it). But let's say he was a bit away from the net, or he 
forgot some build fixes, even 2.6.9 wouldn't have worked for UML.

That said, with mainline inclusion UML is getting more work on from mainline. 
At least, most API changes are handled by the ones who submit them.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
_______________________________________________
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:[~2004-10-28 21:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20041027053602.GB30735@taniwha.stupidest.org>
     [not found] ` <200410282104.30482.blaisorblade_spam@yahoo.it>
     [not found]   ` <20041028193329.GF851@taniwha.stupidest.org>
2004-10-28 20:54     ` Blaisorblade [this message]
2004-10-28 21:42       ` [uml-devel] Re: Why UML often does not build (was: Re: [PATCH] UML: Build fix for TT w/o SKAS) Chris Wedgwood
2004-10-28 23:49         ` Blaisorblade
2004-10-29  0:28           ` Chris Wedgwood
2004-10-29  6:44             ` Werner Almesberger
2004-10-29 14:53               ` Blaisorblade

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=200410282254.21944.blaisorblade_spam@yahoo.it \
    --to=blaisorblade_spam@yahoo.it \
    --cc=akpm@osdl.org \
    --cc=cw@f00f.org \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --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