Re: [uml-devel] UML on PPC progress report

[Chris E. <cem...@ch...>]

On Wednesday, 9 May 2001, Jeff Dike wrote:

> cem...@ch... said:
> > I've finally convinced UML to run user-level code and some system
> > calls on PPC.
> 
> W00T!!  
> 
> How far does it manage to get?  Has it been through any of the tricky system 
> calls (fork, vfork, exec)?  Delivered any process signals?

A system call trace lists: uname, geteuid, getuid, getegid, getgid,
brk*4, getpid, rt_sigaction, getpid, geteuid, getcwd, ioctl (which
returns ENOTTY), more get*id, and read.  At that point I get "Kernel
panic: Attempted to kill init!" as it calls exit (presumably from EOF
on stdin).  So no, none of the tricky ones yet, unless you count the
initial exec, and no signals.

A quick test using a Debian root disk gets a Kernel mode fault during
a read().

> > Jeff, if I split out the more dubious bits, can you commit the
> > rest to CVS at some point?
> 
> Yeah, I'll pull out the portablility fixes first, get them into CVS,
> and send them on to Alan.

Excellent.

> > I've had to change syscall_handler_t to take 5 long arguments rather
> > than a (struct sys_pt_regs).  I _think_ my version should be portable
> > and seems nicer.
> 
> I don't like this one.  Why did you have to do that?

Because as it was, in sys_newuname(struct new_utsname *name), name was
pointing to the sys_pt_regs rather than the user-allocated buffer.  I
can only presume that it works on i386 because function arguments are
passed on the stack anyway.

> > On PPC, TASK_SIZE has to be 0x80000000 instead of 0xc0000000.
> 
> This is wrong even on i386, so it's going to change anyway.

Fair enough.  When's it going to change?  :-)

> > PPC and i386 disagree on the type passed to __[u]delay().  I've
> > added a typedef (currently called um_udelay_t).
> 
> Did you notice that __delay, __udelay, and __const_udelay are all
> wrong?  They all take some period of time as an argument and they
> all ignore it.  Oops.

Oh, yeah.  Doh.  Although it probably doesn't make all that much
difference in UML unless there are some more hardwareish drivers.

> I'll have to think about the other ones.

*nods*

> What's
> 	+#include "asm/delay.h"
> in arch/um/kernel/um_arch.c for?

For loops_per_jiffy, which is declared in asm-ppc/delay.h.

> On the whole, this looks fairly reasonable.

Phew!  :-)

Cheers,

Chris
-- 
Chris Emerson, obsessed Cambridge juggler
E-mail: cem...@ch...
Web page: http://www.chiark.greenend.org.uk/~cemerson/