[User-mode-linux-devel] Re: new syscall, nits, quirks, and blue sky.

[Jeff D. <jd...@ka...>]

> I take it this is the syscall for chroot?

Yup:

grep 61 include/asm-i386/unistd.h  
#define __NR_chroot              61

I'll toss that in.

> Hmmm - tough to preassign modes when devfs (in the host OS) creates
> them on the fly.  I'm sure there's some trickery in devfsd.conf that
> would cause this to happen, but it's not clear what.

For compatibility entries like these, I think the thing you're supposed to do 
is to make them, tar them up, and untar them into /dev at boot time.  That 
will let you keep permissions.

> 	I suspect that simply doing the above with two copies of the debian
> root_fs on fhd0 and fhd1 would _probably_ produce the same effect;

It would.  But that would be bad if they were mounted read-write.

> Specifically, when booting redhat, their [ OK ] and [ FAILED ] prompts
> change color

I tried to make this work.  I flipped on every color-related switch I could 
find in the xterm man page, and none of them did the trick.

> exec of "/sbin/rm" returned -2
> exec of "/sbin/rm" returned -2 
> exec of "/sbin/rm" returned -2

> /dev/xconsole: No such file or directory

At this point, if an error message doesn't seem to be harmful, I'm ignoring 
it.  And I've been ignoring those two for a while.  If anyone wants to figure 
out what's going on, feel free...

> 	What are the chances that I might someday be able to pass off host
> character or block devices to a uml incarnation?  For example: 
> ./ linux-2.3.51 ttyS0=/dev/ttyS0 

You can't do this yet.  It shouldn't be too hard, though.

> ./linux-2.3.51 fd0=/dev/fd0 

You can do that.  Did you try it?  Better to make it fhd1, though :-)  You can
also mount it inside the kernel because I compiled vfat into the binaries.  
CD-ROMs work, too and iso9660 is in there as well.

> all the uml threads label themelves with their job in the uml
> environment.  Nice touch!

I got sick of trying to figure out what all the threads were from the 
outside...

> Is there any thing I can do to help debug this?

First find the panicing thread, which you did (it's the one that goes into a 
tight loop):
> 9881 root      20   0  4124 4124  4120 R N  99.9 10.7   7:51 ./linux-2.3.51 [ls]

SIGUSR1 it : kill -USR1 9881

gdb linux and attach it.
get a backtrace.
get the faulting address from the segv frame.
if kern_segv_handler is on the stack, but not user_segv_handler, grab the 
value of its sc and "p *((struct sigcontext *)0xwhatever)".
then do "i sym 0xwhatever" and "i line *whatever" on sc->eip.

> Interestingly, a different pass shows Unknown HZ value! (19).

I don't know what's going on there.  Something seems to be calculating HZ and 
it seems not to be happy with what it sees.

> Could the routine that tries to allocate hard drive space for
> vm_file check to see if that allocation succeeded, perhaps?

It could.  But the kernel has to be able to deal with running out of memory.  
So I probably have some work to do.

> While hitting Ctrl-D's to exit out of those nested bash'es, uml hung
> and I got: Kernel panic: ptrace PTRACE_PEEKUSER returned 0, errno = 0

You hit some of the debugging code I put in to try to figure out your syscall 
0 problem.  It wasn't the code I hoped you'd hit, though :-(

				Jeff