On Wednesday, 9 May 2001, Jeff Dike wrote:
> cemerson@... said:
> > I've finally convinced UML to run user-level code and some system
> > calls on PPC.
> 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
> > 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.
> > 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.
> +#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.
Chris Emerson, obsessed Cambridge juggler
Web page: http://www.chiark.greenend.org.uk/~cemerson/