User-mode Linux kernel port

Hi

nope i did not change anything becaus ei dont understand it enough
it worked until the cvs update you did yester day.

the cvs on the 1st May worked
now it doesnt

On Thu, 10 May 2001, Jeff Dike wrote:

> mistral@... said:
> > /usr/bin/ld: linux: Not enough room for program headers (allocated 3, need 4)
> > /usr/bin/ld: final link failed: Bad value
> > collect2: ld returned 1 exit status
> > make: *** [linux] Error 1
> 
> I hate it when this happens.  Did you change anything from the last successful 
> build you did (linker, compiler, distro, etc)?  Because I haven't changed 
> anything in link.ld.in lately.
> 
> What you might do is start backing out changes to link.ld.in until you get a 
> good build.  That will tell us what triggered this.
> 
> Every once in a while, after fiddling link.ld.in, I get this.  The error 
> message itself is impenetrable, there are no hints in the docs about what 
> might be happening, and the code around the error is not helpful.  So, I have 
> no clue what it's complaining about or how to fix it.
> 
> 				Jeff
> 
> 

-- 
---------------------------------------------
Check Out: http://stev.org
E-Mail: mistral@...
  7:20pm  up 8 days,  3:16,  5 users,  load average: 41.12, 42.51, 23.86

Try 'make mrproper ARCH=um' then do the entire make config/dep/linux thing
from
the beginning. This happens to me sometimes when I try to recompile
UML after making code changes.

-----Original Message-----
From: user-mode-linux-devel-admin@...
[mailto:user-mode-linux-devel-admin@... Behalf Of
James Stevenson
Sent: Thursday, May 10, 2001 12:27 PM
To: Jeff Dike
Cc: user-mode-linux-devel@...
Subject: Re: [uml-devel] lastest cvs build error



Hi

nope i did not change anything becaus ei dont understand it enough
it worked until the cvs update you did yester day.

the cvs on the 1st May worked
now it doesnt

On Thu, 10 May 2001, Jeff Dike wrote:

> mistral@... said:
> > /usr/bin/ld: linux: Not enough room for program headers (allocated 3,
need 4)
> > /usr/bin/ld: final link failed: Bad value
> > collect2: ld returned 1 exit status
> > make: *** [linux] Error 1
>
> I hate it when this happens.  Did you change anything from the last
successful
> build you did (linker, compiler, distro, etc)?  Because I haven't changed
> anything in link.ld.in lately.
>
> What you might do is start backing out changes to link.ld.in until you get
a
> good build.  That will tell us what triggered this.
>
> Every once in a while, after fiddling link.ld.in, I get this.  The error
> message itself is impenetrable, there are no hints in the docs about what
> might be happening, and the code around the error is not helpful.  So, I
have
> no clue what it's complaining about or how to fix it.
>
> 				Jeff
>
>

Hi

i was working off a clean 2.4.4 tree
eg

tar xzfvp linux-2.4.4.tar.gz
tar cv umlcvstuff
tar xv umlstuff
cp oldmake
make menuconfig
make dep
make linux


On Thu, 10 May 2001, Mooneer Salem wrote:

> Try 'make mrproper ARCH=um' then do the entire make config/dep/linux thing
> from
> the beginning. This happens to me sometimes when I try to recompile
> UML after making code changes.
> 
> -----Original Message-----
> From: user-mode-linux-devel-admin@...
> [mailto:user-mode-linux-devel-admin@... Behalf Of
> James Stevenson
> Sent: Thursday, May 10, 2001 12:27 PM
> To: Jeff Dike
> Cc: user-mode-linux-devel@...
> Subject: Re: [uml-devel] lastest cvs build error
> 
> 
> 
> Hi
> 
> nope i did not change anything becaus ei dont understand it enough
> it worked until the cvs update you did yester day.
> 
> the cvs on the 1st May worked
> now it doesnt
> 
> On Thu, 10 May 2001, Jeff Dike wrote:
> 
> > mistral@... said:
> > > /usr/bin/ld: linux: Not enough room for program headers (allocated 3,
> need 4)
> > > /usr/bin/ld: final link failed: Bad value
> > > collect2: ld returned 1 exit status
> > > make: *** [linux] Error 1
> >
> >
> 

-- 
---------------------------------------------
Check Out: http://stev.org
E-Mail: mistral@...
 12:50am  up 8 days,  8:46,  5 users,  load average: 1.22, 1.33, 0.64

On Thu, 10 May 2001, Jeff Dike wrote:

> Date: Thu, 10 May 2001 14:17:00 -0500
> From: Jeff Dike <jdike@...>
> To: paulwade@...
> Cc: user-mode-linux-devel@...
> Subject: Re: [uml-devel] easy wishlist item 
> 
> paulwade@... said:
> > How about including the .config from the kernel build in the binary
> > package?
> 
> The question is where.  It can't be the root filesystem.  The only other 
> reasonable possibility that I can think of would be something like 
> /var/lib/uml.
> 
> 				Jeff

I mean just include it in any tarball, rpm or deb package wherever you
would normally put readme, changelog, howto, etc. files

So in a debian package it would go in /usr/share/doc/<packagename>

pw

Jeff,

How about including the .config from the kernel build in the binary
package? Debian places a renamed(e.g. config-2.2.19-ide) copy in the /boot
directory when installing a kernel-image package. They also include a copy
named kernel-config with the install disk images. This type of thing is so
very handy for someone who wants to know how the kernel was built and
maybe wants to build one with only a slight difference.

pw

While I like the idea of an easier to use bridge between UML and the
host Linux, I wonder why use the Ethertap driver? According to the
Doc..../network/ethertap.txt file with the 2.4.4 kernel:

NOTE: Ethertap is now an obsolete facility, and is scheduled
      to be removed in the 2.5.x kernel series.  Those writing
      applications using ethertap should convert their code to
      use the TUN/TAP driver instead, see 'tuntap.txt' in this
      directory for more details. 
-DaveM                                       

If the ethertap driver is considered obsolete, why are we using it?

Mark

Jeff Dike wrote:
> 
> I've checked in the ethertap backend for the network driver.  To use it, you
> need to configure both CONFIG_NET_UMN and CONFIG_NET_UM_ETH.  You also need
> ethertap_helper, which is in /tools/net/ethertap_helper.c.  Compile it, make
> it suid root, and stick it someplace in your path.
> 
> Run UML with 'ethertap=<interface>,<tap address>,<UML address>' on the kernel
> command line.  I've been using 'ethertap=tap0,192.168.0.251,192.168.0.252'.
> The tap address is the address of the tap device on the host, and UML address
> is the eth0 address inside UML.
> 
> I've been ifconfiging as follows:
>         ifconfig eth0 192.168.0.252 hw ether fe:fd:0:0:0:0 up
> 
> The helper does all the setup on the host, except that ethertap needs to be in
> the kernel already.  Ultimately, I intend to merge all of the suid helping
> into a single helper, which will do everything possible to set things up on
> the host.  I hope this will eliminate the setup nightmares that people have
> with UML networking.
> 
> One thing I've been unable to do is communicate with the outside net through
> the tap device.  I've tried all the arp and routing tricks I know, but the
> other machine can't reach it, or vice versa.  The other box arps it fine, but
> pings just get dropped.  Packet forwarding is on.  If anyone knows of anything
> I might have missed, let me know.
> 
> Also in this batch is the removal of thread.starting_exec, which is no longer
> necessary, and was causing hangs for mistral, although he thinks it's still
> happening with an earlier version of this fix.  We'll see...
> 
>                                 Jeff
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@...
> http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

--
==========================================================================
Mark Buckaway             Tel: 416-203-4582   http://www.platespin.com
Sr. Software Developer    Fax: 416-203-0621   Email: markb@...
Platespin Inc.      Reception: 416-203-6565
--------------------------------------------------------------------------
The statements made in this message are the opinions of the author and
may or may not reflect the opinions of Platespin Inc.
--------------------------------------------------------------------------

cemerson@... 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?

> 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.

>	ELF_SUBARCH stuff for link.ld
>	The hostfs pointer fix is included.
> PPC doesn't have ptrace(PTRACE_GETREGS...,
> I moved a comma from after ARCH_SYSCALLS in the definition of
> sys_call_table to inside the macro definition.
> Various explicit register references replaced by generic UM_SP
> etc. macros.
> Introduced UM_GET_SC macro to get the sigcontext_struct *
> The stuff in arch/um/ptproxy/sysdep.c now uses the same
> defines for register offsets from sysdep/ptrace.h as the rest of the
> code uses.

These are fine.

> 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?

> On PPC, TASK_SIZE has to be 0x80000000 instead of 0xc0000000.

This is wrong even on i386, so it's going to change anyway.

> 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.

I'll have to think about the other ones.

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

On the whole, this looks fairly reasonable.

				Jeff

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.
> 
> 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: cemerson@...
Web page: http://www.chiark.greenend.org.uk/~cemerson/

Hi there

Is it possible to move the mailing lists from Geocrawler to
Sourceforge? Geocrawler is down several hours every day for
"nightly database maintenance". It has been like this since I started 
to monitor UML a few weeks ago.

 Jocke

I've been trying to run dynamically linked binaries under PPC, and
found that mmap() doesn't yet work.  The first problem is that the
signature of old_mmap() has a different signature on i386 due to an
old limitation on the numer of syscall arguments (see comment in
syscall_kern.c).

I think the sensible thing to do is to move the old_mmap entry in
sys_call_table into ARCH_SYSCALLS.  i386 can then replace it with a
wrapper which extracts parameters appropriately.  The same will need
to be done to old_select() by the looks of it.  Jeff, do you think
there's a better way?

The second problem with mmap() I'm still working on.  It's reporting
"kernel BUG at memory.c:370".  I think I'm going to have to step
through an x86 UML and compare what happens.

Cheers,

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

cemerson@... said:
> A quick test using a Debian root disk gets a Kernel mode fault during
> a read(). 

This might be copy_from_user messing up.

> 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.

OK, something in there might need to move into arch-specific code.  If we let 
the arch define sys_call_handler_t and the actual invocation of the system 
call, that ought to do it.

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

Probably soon.  The problem on i386 is the 2G user/2G kernel option.  That 
makes TASK_SIZE 0x80000000 rather than 0xc0000000.  Is the process stack at 
the top of the address space on ppc?  What I'm thinking of doing is rounding 
the sp up to the nearest 256M and using that as TASK_SIZE.

				Jeff

On Thursday, 10 May 2001, Jeff Dike wrote:

> cemerson@... said:
> > A quick test using a Debian root disk gets a Kernel mode fault during
> > a read(). 
> 
> This might be copy_from_user messing up.

Could be.  I'll look into it at some point.

> > 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.
> 
> OK, something in there might need to move into arch-specific code.
> If we let the arch define sys_call_handler_t and the actual
> invocation of the system call, that ought to do it.

Why do you want to pass the struct sys_pt_regs through like that, even
on i386?  I'm slightly surprised it works as it is, but then I may be
missing something.

> > Fair enough.  When's it going to change?  :-)
> 
> Probably soon.  The problem on i386 is the 2G user/2G kernel option.
> That makes TASK_SIZE 0x80000000 rather than 0xc0000000.  Is the
> process stack at the top of the address space on ppc?  What I'm
> thinking of doing is rounding the sp up to the nearest 256M and
> using that as TASK_SIZE.

It's a bit icky, but I think it would work.  Linux clearly needs a
proper configure script.  ;-)

Cheers,

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