linux-um archives
 help / color / mirror / Atom feed
From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Jeff Dike <jdike@addtoit.com>,
	Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Subject: Re: [uml-devel] What to send to Andrew next
Date: Fri, 22 Oct 2004 18:52:27 +0200	[thread overview]
Message-ID: <200410221852.27232.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <200410220516.i9M5GwFL007932@ccure.user-mode-linux.org>

On Friday 22 October 2004 07:16, Jeff Dike wrote:
> We've pretty much got -mm and -linus caught up with the updates that had
> been sitting around.
Yes, our new development way is very effective.
> At this point, my patch list is a mix of things that both are and aren't
> ready for prime time.  So, I'd like opinions on what's ready.

> The names below are the ones at
> 	http://user-mode-linux.sourceforge.net/patches.html

> Here's my take on it:
>
> Ready -
> 	catch_eintr_generic_console_write
I changed slightly the comment:
               /* The terminal becomes a bit less raw, to handle \n also as
                * "Carriage Return", not only as "New Line".
And added:

Otherwise, the new
                * line won't start at the first column.*/

I'm sending it now.
> 	fix-some-warnings - some things left over from your patch
> 	need-bash - I changed the comment :-)
Both already applied.
> 	syscall-returns - the start of the x86_64 stuff, this one cleans up
> int -> long declarations in the system calls
> 	type-sizes - ditto for some other types

> 	syscalls - factors the system calls between generic and arch-specific
> a bit better, I consider this safe because you can look at sys_call_table
> before and after and see that they're the same
I think this is not needed for now - however, I'll write some script for doing 
the check by hand.

And why on x86_64 you do:
#define NR_syscalls 1024
?

> 	tmp-exec
Agreed
> 	defconfig
Probably outdated - I already updated the defconfig here and I'll merge that.
> 	smp-link
Agreed, but I added the same change to the dyn.lds.S script, so I'll send this 
myself. Don't answer "SKAS does not support SMP" - it does not hurt, so let's 
avoid fixing it only when we start SKAS + SMP support.

> 	fix-ptrace-interfaces - straightforward interface fixes
Yes, agreed.

> 	no-chans - makes sure something hits the screen when someone makes
> a bogus config
NO: But why does not the no_config prints a meaningful message? We could also 
insert some #error directives when nothing of this is selected.
When you select no Block Scheduler (no deadline, no CFQ, nothing...) you get a 
#error, in fact.

> 	no-timestamp
Ok.
> 	comments
Ok.

Missing at least:

irq-bits - needed for mainline updates at least since -bk4, but not complete.
Other stuff, which I have here:
-some stuff about SYSEMU support, coming from Bodo work, to fix bugs 
introduced by me/you/Laurent.
- some patches I already sent to the ML and to you to review, which got no 
answer. I want them reviewed, but you should give a look to your mails...

1) FOR INSTANCE, I sent the patch avoiding SIGPROF being touched by 
change_signals(). Why did not you bother at it?
2) copy_from_user_skas() does not make sense. When accessing the page tables, 
they would be happy to get some locking. If you want to take a look to the 
4G-4G patch from Ingo Molnar, which must do something identical, 

> Uncertain -
> 	use-va_end - looks good to me, but have you figured out why it causes
> crashes?
No, I'm busy with other work - SYSEMU. It will be sorted out before 2.6.10, 
however.

> 	export-Symbols - I need to look at that phys_t change, which doesn't
> belong there
Everything apart the "phys_t" change is already merged.

> 	Single_Linking_Step - leftovers, build linux, add archhelp, you
> sent something like this to Andrew, so this may be essentially already
> there

Yes, already in 2.6.9.

> do_signal and the rest of Bodo's fixes - I want his test cases before 
> I send these anywhere, although the ones that make UML look like the other
> arches might be OK.
Well, yes, but let's try to be fast on these. They are very good patches and 
fix also security problems.
> Dangerous -
> 	3-level-pagetables and the rest of the x86_64 stuff
Yes, it must wait.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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-22 16:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-22  5:16 [uml-devel] What to send to Andrew next Jeff Dike
2004-10-22 16:52 ` BlaisorBlade [this message]
2004-10-22 21:28   ` Jeff Dike
2004-10-23  3:57     ` BlaisorBlade
2004-10-25  9:05     ` Bodo Stroesser

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=200410221852.27232.blaisorblade_spam@yahoo.it \
    --to=blaisorblade_spam@yahoo.it \
    --cc=bstroesser@fujitsu-siemens.com \
    --cc=jdike@addtoit.com \
    --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