user-mode-linux-devel

Re: [User-mode-linux-devel] uml ethernet interface - code

[Gerald B. <gbr...@mi...>]

On Sun, Apr 30, 2000 at 09:28:08AM -0500, Jeff Dike wrote:
> gbr...@mi... said:
> > You can send much more arbitrary network data, more protocols, etc.
> 
> I'm just taking arbitrary bits, coding them up a bit, and sending them down 
> the slip line.  I think what happens in the kernel is that those bits get 
> reconstituted and passed into the network code.  I don't see any generality 
> problems there.

This doesn't actually work for protocols other than IP.  You can't send such
things as AppleTalk over the SLIP link.

> > Also, it allows you to setup bridging fairly trivially on the host
> > such that eth0 is bridged to tap0 which would let you have the uml
> > hosts appearing on the same outer network as the host
> 
> How is this different from having umn bridged to sl0, and putting the uml 
> hosts on the outer net?

You cannot bridge ethernet traffic onto a SLIP link.  The point is raw
ethernet frames are reproduced onto the other side of the bridge, which is
impossible over SLIP because you are limited to IP traffic and lose the lower
layer of information.  Also, SLIP is a point-to-point link which is not
particularly useful for communication to multiple UMLs running on a single
machine.  If there are say 4 UML sessions running on a single machine, you
would need 4 separate SLIP connections and individual routes for each of them
to get them visible to the outside world.  With the solution I'm talking about,
you would simply need to setup uml-net with the ethertap device on the host
machine, and setup a bridge between eth0 and tap0.  Now every UML which is
using uml-net can simply configure its eth0 as if it were on the host's
ethernet directly.

				-- Gerald

Re: [User-mode-linux-devel] Compile problems on Redhat 6.0/6.1

[Michael V. <is...@ne...>]

On Sun, 30 Apr 2000, Jeff Dike wrote:
>
> This looks familiar.
> 
> Do you install the patch against a kernel pool in /usr/src/linux?  If you did, 
> then make /usr/src/linux/include/asm point back to 
> /usr/src/linux/include/asm-i386, copy the pool someplace else, and apply the 
> patch to it there.

Thanks.  It compiles fine now.  I assumed that you had to build uml like a
regular kernel but I guess not.  

If you follow the steps in section 2.2 of the HOWTO, it tells you to build
the uml kernel from /usr/src/linux though.  I guess this information is
wrong for RedHat distributions?

Michael

Re: [User-mode-linux-devel] uml ethernet interface - code

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

gbr...@mi... said:
> You can send much more arbitrary network data, more protocols, etc.

I'm just taking arbitrary bits, coding them up a bit, and sending them down 
the slip line.  I think what happens in the kernel is that those bits get 
reconstituted and passed into the network code.  I don't see any generality 
problems there.

> Also, it allows you to setup bridging fairly trivially on the host
> such that eth0 is bridged to tap0 which would let you have the uml
> hosts appearing on the same outer network as the host

How is this different from having umn bridged to sl0, and putting the uml 
hosts on the outer net?

				Jeff

Re: [User-mode-linux-devel] Compile problems on Redhat 6.0/6.1

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

> It looks like the standard libc headers are interfering with uml's asm/
> unistd.h in arch/um/kernel/{syscall_user.c,trap_user.c}.

This looks familiar.

Do you install the patch against a kernel pool in /usr/src/linux?  If you did, 
then make /usr/src/linux/include/asm point back to 
/usr/src/linux/include/asm-i386, copy the pool someplace else, and apply the 
patch to it there.

				Jeff

[User-mode-linux-devel] Compile problems on Redhat 6.0/6.1

[<is...@ne...>]

Hi,

I recently started playing with uml. I tried to build the linux executable
myself this evening and encountered some gcc errors.  I tried building it
on a fresh RedHat 6.0 system and a fresh RedHat 6.1 system but encountered
the same compile errors.  It looks like the standard libc headers are
interfering with uml's asm/unistd.h in
arch/um/kernel/{syscall_user.c,trap_user.c}.

Has anybody else encountered this problem?  I was surprised that it didn't
compile successfully on a Redhat distribution.  It makes me think I'm
doing something wrong, but I don't know what.

Anyways, I've attached a patch against pre5 which works for me.  I haven't
tried it with pre6 though.  Maybe somebody who has more than 2 hours
experience with uml could take a look at it and let me know what I'm doing
wrong :)

Thanks,
Michael

Re: [User-mode-linux-devel] uml ethernet interface - code

[Gerald B. <gbr...@mi...>]

> > this could probably be enhanced a bit adding ethertap support to
> > uml-net so it can potentially communicate with the host os, this was
> > an idea i'd had before but hadn't thought of it possibly communicating
> > with multiple uml's on the same machine.
>
> I think there are basically two kinds of possible nets here - ones that 
> communicate with the host os and ones that just communicate between umls.  I 
> don't see any reason that they should be combined.  I'm happy with a 
> point-to-point driver that connects to the host and a ethernet-like driver 
> that lets a bunch of umls talk to each other.

The thought I had was that the ethertap interface is much more versitile
than a slip interface.  You can send much more arbitrary network data, more
protocols, etc.  Also, it allows you to setup bridging fairly trivially on
the host such that eth0 is bridged to tap0 which would let you have the uml
hosts appearing on the same outer network as the host, just as vmware does
bridging (though it does it through a slightly different manner).

				-- Gerald

[User-mode-linux-devel] New version of uml ethernet interface

[James R. L. <jl...@mi...>]

I spent some time today refining and adding to my ethernet interface
for user-mode linux.  I is a bit more resiliant now, still not one hundred
percent though.  I am attaching the diff vs uml pre6 version.  I put the
userland utils (uml-net and uml-set) into the linux/drivers/net/uml-net
directory.  I know this against the rules, but it make my life easier
for now.

Here is how to use it: (starting from a raw Linux 2.3.99-pre6 kernel)

(first add the UML patch - patch-2.3.99-pre6.bz2)
cd linux
bzip2 -dc ../patch-2.3.99-pre6.bz2

(then my patch)
patch -p1 < ../uml.diff

(nothing new here)
make menuconfig
make linux

(the userland uml-net utils)
cd drivers/net/uml-net/
make

(mount the uml root file systems so you can copy a utility into them)
mount -o loop -t ext2 root_fs /mnt
cp uml-set /mnt/root/

Now start start them up:

(in window one start 'uml-net' from linux/drivers/net/uml-net/)
./uml-net

(in window two start a uml kernel)
(in window three start another uml kernel)
NOTE!! you should be using seperate root file systems for these!!

(in windows two, after logging in in as root)
ifconfig eth0 hw ether 0:0:10:0:0:1
ifconfig eth0 10.0.0.1

ifconfig eth1 hw ether 0:0:11:0:0:1
ifconfig eth1 11.0.0.1
./uml-set eth1 101

(in windows three, after logging in in as root)
ifconfig eth0 hw ether 0:0:10:0:0:2
ifconfig eth0 10.0.0.2

ifconfig eth1 hw ether 0:0:11:0:0:2
ifconfig eth1 11.0.0.2
./uml-set eth1 101

This is kinda of lame example because its not really fun connecting
2 uml's together with two ethernet :-)

In theory you should be able to start up as many uml's as you like, and
then network them together in any way you want.

A couple of notes:
- by default each uml has 4 ethenets (eth0-3), this is hard coded, I don't
  know how to write my code to respect the "ether=,,,eth0" kernel command line
- 'uml-set' set's which broadcast domain (net_num) you want the interface to be
  in. (the default net_num in 100 all interface be default are a member of it)
- just execute the uml-set command on any interface on any uml that you
  want to 'hear' packets for a particular broadcast domain (net_num)
- you can only set the hw address when the interface is down
- you can only set the uml broadcast domain (net_num) when the interface
  is up
- the best order of operation is to set the hw address as soon as the uml comes
  up.  You can bring up the interface right after that.  They feel
  free to change the IP address and broadcast domain as much as you want
  just don't be bringing down the interfaces!
- don't be bringing interface up then down too much, the uml's tend to crash :-)
- don't be shutting down the uml-net process when uml's are connected to it
  the uml's tend to crash :-)
- for some reason one uml thread stays behind after shutting down a uml
  you'll want to kill these, unless you have CPU cycles to burn :-)
- you'll notice weird delays between pings.  I'm not sure where this is coming
  from. I think uml's are experiencing time warps :-)
- multicast doesn't work yet, that's the next feature to add.

Have fun.

Jim
-- 
James R. Leu

Re: [User-mode-linux-devel] uml ethernet interface - code

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

jl...@mi... said:
> I notice that you have a request_irq() implementation but I couldn't
> find a do_IRQ() or equivalent.  Do you have equivalent or do you by
> pass the interrupt scheme completly? 

I don't have device interrupts at all yet.  Everything is driven off the timer.

The way input works is that the initial uml thread becomes the input handler 
for the whole kernel.  Anything that wants to listen to a file descriptor 
opens it and pass it plus a callback procedure to input_new_fd.  That 
procedure will be called whenever there's input on the fd.  When the fd is 
emptied, the callback calls enable_fd to have monitoring of it resumed.  When 
it is closed, call input_forget_fd.  Look at arch/um/drivers/umn_user.c to see 
this in action.

The irq code that is there is a historical artifact from when I was first 
getting the kernel to link.  I added the entry point, then looked at the i386 
implementation, saw that there was no funky assembly or anything in it, and 
copied it in.  It's not used and I just haven't got rid of it yet.

> I've attached the diff (vs pre5, but it works on the new pre6 as well)
> and the code for the (very) simple net program. 

I didn't get anything in the attachment...

gbr...@mi... said:
> this could probably be enhanced a bit adding ethertap support to
> uml-net so it can potentially communicate with the host os, this was
> an idea i'd had before but hadn't thought of it possibly communicating
> with multiple uml's on the same machine.

I think there are basically two kinds of possible nets here - ones that 
communicate with the host os and ones that just communicate between umls.  I 
don't see any reason that they should be combined.  I'm happy with a 
point-to-point driver that connects to the host and a ethernet-like driver 
that lets a bunch of umls talk to each other.

The choice of how to talk to the host is one of permissions as far as I know.  
The current driver uses a slip device.  I looked at using ethertap a while 
back, but it seems to have the same requirements as slip.  You need to be root 
or have CAP_NET_ADMIN to configure one.

jl...@mi... said:
> I have plans to use either ethertap or an AF_PACKET socket that can
> listen too and send packets out a specific physical interface.

Unless you can think of a good reason that you need to add host networking to 
your driver, I would just leave it as a virtual network driver...

				Jeff

Re: [User-mode-linux-devel] uml ethernet interface - code

[James R. L. <jl...@mi...>]

On Sat, Apr 29, 2000 at 04:02:36PM -0400, Gerald Britton wrote:
> > I have a bare bones ethernet interface working in UML.  It uses an external
> > process (uml-net) to handle the connection between multiple uml's.
> 
> hrmm.. idea: this could probably be enhanced a bit adding ethertap support
> to uml-net so it can potentially communicate with the host os, this was
> an idea i'd had before but hadn't thought of it possibly communicating
> with multiple uml's on the same machine.

I have plans to use either ethertap or an AF_PACKET socket that can listen
too and send packets out a specific physical interface.  Either of these
should be fairly easy to add to the uml-net program.

Jim

-- 
James R. Leu

Re: [User-mode-linux-devel] uml ethernet interface - code

[Gerald B. <gbr...@mi...>]

> I have a bare bones ethernet interface working in UML.  It uses an external
> process (uml-net) to handle the connection between multiple uml's.

hrmm.. idea: this could probably be enhanced a bit adding ethertap support
to uml-net so it can potentially communicate with the host os, this was
an idea i'd had before but hadn't thought of it possibly communicating
with multiple uml's on the same machine.

				-- Gerald

[User-mode-linux-devel] uml ethernet interface - code

[James R. L. <jl...@mi...>]

Jeff,

I have a bare bones ethernet interface working in UML.  It uses an external
process (uml-net) to handle the connection between multiple uml's.

Current it only support one broacast domain.  I plan on fixing that today.

I did want to raise one question:  In the native kernels a drive does a
request_irq() and registers a interrupt call back.  When an interrupt
is received it is processes and then set to do_IRQ() for furture dispatching.

I notice that you have a request_irq() implementation but I couldn't find
a do_IRQ() or equivalent.  Do you have equivalent or do you by pass the
interrupt scheme completly?

I've attached the diff (vs pre5, but it works on the new pre6 as well)
and the code for the (very) simple net program.

(please remember that this is the result of only a few hours of programming
and is more of a proof of concept then anything else)

Here is how to use it:
----------------------------------------------------

Apply the patch:
cd linux-kernel-uml-pre6
patch -p1 < ../uml.diff

Re-compile the uml kernel:
make linux

Compile the net program:
gcc -o uml-net uml-net.c

Start up two uml's:
cd ../uml-1
../linux-kernel-uml-pre6/linux devfs=mount

(in another window)

cd ../uml-2
../linux-kernel-uml-pre6/linux devfs=mount

Start the net process:
./uml-net

Bring up the uml intefaces:
(in uml-1)
ifconfig eth0 down
ifconfig eth0 hw ether 0:0:10:0:0:1
ifconfig eth0 10.0.0.1 up

(in uml-2)
fconfig eth0 down
ifconfig eth0 hw ether 0:0:10:0:0:2
ifconfig eth0 10.0.0.2 up

Test the uml network connection:
(in uml-1)
ping 10.0.0.2

(in uml-2)
ping 10.0.0.1

-- 
James R. Leu

Re: [User-mode-linux-devel] UML on non-x86?

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

> Well, there's at least one now... 

Cool...

> Here are some notes from what I've done so far... 

Can you make your ongoing diffs available somewhere?  I'm going to run a 
parallel effort and do the i386 port.

> but a lot of the time it's just things like changing "UESP" to "PT_R1"
> or whatever it is.  I haven't yet decided whether I think having
> constants like "UM_STACK_REGISTER" or "UM_RETURN_REGISTER", or whether
> it's better to keep the code entirely separate.

If it's just a matter of changing the register number, and the logic is 
exactly the same, I was planning on introducing things like UM_SP and UM_IP, 
and have the different arches define them.

> The pt_regs structure (the ppc one, not the um one) is quite different
> (unsurprisingly).  I've been using that in a few places instead of an
> array of length 17, eg the thread_struct.

The register arrays are going to have to analagous to the thread structure - 
defined by the underlying arch and included in the thread structure, so the 
i386 unsigned long[17] will go into the i386 arch and you can define whatever 
you need for ppc.

> The checksum.S linked to from the arch/ppc/lib didn't compile, since
> some of the redirected <asm/*.h> includes broke things.  For now I've
> copied the file and included some stuff from <asm-ppc/*.h>. 

Things like this will need to be handled by the arch.  I guess I can include 
the arch Makefile and it can add things to $OBJS.  BTW, feel free to steal 
code from arch/ppc.  It saves a lot of work :-)

> How far away is that?  :-)

Pretty far, I think :-)

				Jeff

Re: [User-mode-linux-devel] UML on non-x86?

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

On Fri, 28 Apr 2000, Jeff Dike wrote:

> As far as I know, there are no ongoing porting efforts.

Well, there's at least one now...

[things which need to be done]
> 	You need to get uml to compile with the include/asm-um/arch
> link pointing to ../asm-ppc in your case.  Almost all of the asm-um
> headers just #include their arch equivalents.  You'll need to find
> the exceptions for ppc.
> 	Once it compiles, look at all the places that registers are
> referenced.  These are in close proximity to ptrace calls, so
> grepping for ptrace will show you where they are.  Replace those
> with the ppc equivalents.

Well, I've tweaked things far enough to make vmlinux, although the
runnable binary doesn't link so far.  There are unresolved references
to things like atomic_dec, atomic_inc, and local_bh_count.  I'll look
into those next.

> 	Run it and watch it work :-)

Once I get it to link, I'll find out how badly I've broken it.  :-)

> If you do start working on this, I need to know what you're running
> into so I can start thinking about how to abstract the architecture
> stuff out of the main code.  So, keep me updated.

Here are some notes from what I've done so far...

General: I had to change the SUBARCH bit in the configuration, and the
odd mention of i386 (eg -U__i386__ -> -U__powerpc).  The linker script
in arch/um also specified the architecture.

Registers: There are some places where the code has to be changed
quite a lot (eg special handling for segment registers), but a lot of
the time it's just things like changing "UESP" to "PT_R1" or whatever
it is.  I haven't yet decided whether I think having constants like
"UM_STACK_REGISTER" or "UM_RETURN_REGISTER", or whether it's better to
keep the code entirely separate.

The pt_regs structure (the ppc one, not the um one) is quite different
(unsurprisingly).  I've been using that in a few places instead of an
array of length 17, eg the thread_struct.  I can get away with this
since the PT_foo defines for register offsets are documented as
working with the pt_regs structure, but this isn't ideal.  I haven't
put much thought into it so far.

The checksum.S linked to from the arch/ppc/lib didn't compile, since
some of the redirected <asm/*.h> includes broke things.  For now I've
copied the file and included some stuff from <asm-ppc/*.h>.

old-checksum.c doesn't exist in PPC, so I removed it from the
Makefile.

I found a typo in one of the PPC headers (SRGV_ACCERR instead of
SEGV_ACCERR).  Assuming I didn't manage to insert it accidentally
myself, I should submit the patch to the kernel people, I suppose.

> My current thinking is that we can put the machine dependent stuff
> under a generic interface like the upper kernel does now.  We'll
> have arch/i386, arch/ppc, etc somewhere under the arch/um layer.

I think that makes sense.  I'll leave that until I have things
working, though...

> Longer term, this may get ported to other OS's, in which case the
> host OS would be the visible architecture, and the arch/* that I
> just described would move under os/linux or something.

How far away is that?  :-)

Cheers,

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

Re: [User-mode-linux-devel] UML on non-x86?

[lars b. <la...@no...>]

Chris Emerson <cem...@ch...> writes:
> I see that for now umlinux is x86 only at the moment.  I'd quite like
> to see it working on other architectures, particularly powerpc.  Has
> anyone done any work towards it?  If so, then I'd like to help.  If
> not, I'd like to have a go at it and would appreciate someone pointing
> me in the right direction to get started.  :-)

Not that Linux/a386 is anything near as functional as uml is, but it's
designed with a very clear separation of the architecture-dependant
stuff: Linux/a386 itself written completely in portable C code, and
the a386 hardware abstraction library contains C and assembler implementing
all architecure-dependant functionality.

http://linux.a386.nocrew.org/
http://a386.nocrew.org/

Re: [User-mode-linux-devel] UML on non-x86?

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

> If so, then I'd like to help.  

As far as I know, there are no ongoing porting efforts.

> If not, I'd like to have a go at it and
> would appreciate someone pointing me in the right direction to get
> started.  :-)

Here are the major items:
	You need to get uml to compile with the include/asm-um/arch link pointing to 
../asm-ppc in your case.  Almost all of the asm-um headers just #include their 
arch equivalents.  You'll need to find the exceptions for ppc.
	Once it compiles, look at all the places that registers are referenced.  
These are in close proximity to ptrace calls, so grepping for ptrace will show 
you where they are.  Replace those with the ppc equivalents.
	Run it and watch it work :-)

I believe that those two things are it, but since a port has not yet been 
done, I don't know for sure.

If you do start working on this, I need to know what you're running into so I 
can start thinking about how to abstract the architecture stuff out of the 
main code.  So, keep me updated.

My current thinking is that we can put the machine dependent stuff under a 
generic interface like the upper kernel does now.  We'll have arch/i386, 
arch/ppc, etc somewhere under the arch/um layer.

Longer term, this may get ported to other OS's, in which case the host OS 
would be the visible architecture, and the arch/* that I just described would 
move under os/linux or something.

				Jeff

[User-mode-linux-devel] UML on non-x86?

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

I see that for now umlinux is x86 only at the moment.  I'd quite like
to see it working on other architectures, particularly powerpc.  Has
anyone done any work towards it?  If so, then I'd like to help.  If
not, I'd like to have a go at it and would appreciate someone pointing
me in the right direction to get started.  :-)

Cheers,

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

[User-mode-linux-devel] 2.3.99-pre6 changes are checked in

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

I've started phasing out the fhd device name and the major number 68 in favor 
of the official ubd name and its official major number 98.  fhd will work for 
a while.  At this point it shares its state with the ubd driver.

The umn driver now supports the umn=[ip address] switch on the command line.

The idle loop now sleeps instead of spinning.

I fixed a whole batch of signal delivery bugs including:
	They are delivered one at a time with a kernel exit each time to allow the 
signal mask to be reset correctly.
	Unhandled seg faults are now passed along to the process
	sigcontext_structs are now passed in to signal handlers

Fixed the stack limit bug that Gerald Britton found.  The problem there was 
that bad things happened when the user-mode kernel put stacks within the 
stacklimit range of the real stack.  The fix was to set the stacklimit down if 
it is too large and made sure that all other stacks are outside that limit.

One more thing that you should be aware of is that devfs changed its default 
behavior in this release.  It no longer mounts itself by default.  So, if 
you're using devfs, you should start adding 'devfs=mount' to the command line, 
or the kernel won't boot too well.

				Jeff

Re: [User-mode-linux-devel] init weirdness

[Gerald B. <gbr...@mi...>]

On Wed, Apr 12, 2000 at 01:19:55PM -0500, Jeff Dike wrote:
> If -pre3 does the same thing, did it ever work?  If so, what did you change :-)

I haven't ever gotten it to work and haven't changed anything.

> That ls makes it look like you grabbed the Debian package.  Is it still the 
> stock root_fs, or did you do anything to it?  I just booted up that root_fs to 
> check, and it works fine for me.

Yep, it's the debian package.

> I'm going to back off my earlier claim that it doesn't matter what you're 
> booting from.  I can't think of anything else that makes any sense.  There's 
> no way that it should be trying to exec ld.so, which is what I think that 
> error message is saying.

When executing any dynamically linked executable, ld.so is run to link in all
the librarys the program uses.

> Can you try making and booting a tiny filesystem with init, the shared 
> libraries that it needs, ld.so, and maybe an inittab?  Just enough stuff to 
> get init up and running a little.  If that works, then that would make it look 
> like something's wrong with the root filesystem.

It does the same thing with any dynamically linked executable used as init,
if i use a statically linked executable as init, that works.  But I then cannot
execute anything.  If i try, the kernel panics with the message "Bogus address
in segv"

				-- Gerald

Re: [User-mode-linux-devel] init weirdness

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

If -pre3 does the same thing, did it ever work?  If so, what did you change :-)

That ls makes it look like you grabbed the Debian package.  Is it still the 
stock root_fs, or did you do anything to it?  I just booted up that root_fs to 
check, and it works fine for me.

I'm going to back off my earlier claim that it doesn't matter what you're 
booting from.  I can't think of anything else that makes any sense.  There's 
no way that it should be trying to exec ld.so, which is what I think that 
error message is saying.

Can you try making and booting a tiny filesystem with init, the shared 
libraries that it needs, ld.so, and maybe an inittab?  Just enough stuff to 
get init up and running a little.  If that works, then that would make it look 
like something's wrong with the root filesystem.

				Jeff

Re: [User-mode-linux-devel] init weirdness

[Gerald B. <gbr...@mi...>]

I'm just running it in an xterm.  I got essentially the same results when
running the previous 2.3.99-pre3 version.  A capture of the console output
is below.

				-- Gerald

% ls
2.3-patch*  README  UserModeLinux-HOWTO.txt  linux*  root_fs
% ./linux
signal thread pid = 5415
idle thread pid = 5416
Linux version 2.3.99-pre4-1um (jd...@cc...) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #143 Tue Apr 11 19:50:22 EST 2000
On node 0 totalpages: 4096
zone(0): 256 pages.
zone(1): 3840 pages.
zone(2): 0 pages.
Calibrating delay loop... 241.17 BogoMIPS
Memory: 16080k available
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Starting kswapd v1.6
pty: 256 Unix98 ptys configured
Initializing stdio console driver
Initializing software serial port version 0
                                           serial line 0 assigned pty /dev/ptyp0
ssl receive thread is pid 5421
                              devfs: v0.93 (20000306) Richard Gooch (rg...@at...)
          devfs: devfs_debug: 0x0
                                 devfs: boot_options: 0x0
                                                         VFS: Mounted root (ext2 filesystem) readonly.
                      Mounted devfs on /dev
                                           Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we get handle
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RPATH information in object names in LIST

Re: [User-mode-linux-devel] init weirdness

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

Can you show us the console output?  

I don't think it matters, but what are you booting it from?

				Jeff

[User-mode-linux-devel] init weirdness

[Gerald B. <gbr...@mi...>]

After downloading the 2.3.99-pre4-1um kernel and trying to boot it, I get
this message when trying to run init:

Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
. . .

It's acting as if it's not properly passing arguements to the dynamic linker
when it executes.  I can get it to run if i boot with init=/sbin/sash.  sash
comes up and runs and I can do stuff in it, but if i try to execute anything,
I get a kernel segfault error.

My host system is a 2.2.15pre16+ext3+kdb+autofs4 SMP kernel running redhat 6.1.

any ideas?

[User-mode-linux-devel] Re: user-mode minix

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

Pretty cool.  I just poked around that web site, and it is exactly the same 
idea.

I think uml is more significant than smx if for no other reason that linux is 
more significant than minix.

				Jeff

[User-mode-linux-devel] user-mode minix

[lars b. <la...@no...>]

Interestingly, what is being done for Linux has long since been done for
MINIX: Solaris MINIX is MINIX running as a SunOS process.

http://www.cosc.canterbury.ac.nz/~paul/smx.html

[User-mode-linux-devel] News from the trenches

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

I've got ptrace implemented enough that strace now works.  gdb doesn't yet 
because I haven't put in code to deal with hitting breakpoints.

Having strace working gave me the ability to figure out why it was impossible 
to telnet into a uml.  It turned out that in this code, where the lock was 
being turned off, and *arg == 0, get_user was setting val so something very 
non-zero, so the pty stayed locked, and the open of the slave side failed:

/* Set the lock flag on a pty */
static int pty_set_lock(struct tty_struct *tty, int * arg)
{
	int val;
	if (get_user(val,arg))
		return -EFAULT;
	if (val)
		set_bit(TTY_PTY_LOCK, &tty->flags);
	else
		clear_bit(TTY_PTY_LOCK, &tty->flags);
	return 0;
}

get_user looked like this:

#define get_user(x, ptr) \
({ __typeof__(*(ptr)) val; \
   memcpy(&val, (ptr), sizeof(*(ptr))); \
   (x) = (__typeof__(*(ptr))) val; \
   0; \
}) 

Spotted the bug?

I stared at it for a while before figuring out that the get_user val was 
hiding the pty_set_lock val.  Ironically, the compiler had been trying to tell 
me for ages about this.  It had always complained about val maybe not being 
used and I had looked at it and decided that it didn't know what it was 
talking about.  I think one a Henry Spencer's 10 Commandments is "Study the 
pronouncements of the compiler with care".  I should have.

I fixed another bug in the network driver which fixed the problem with 
outgoing tcp connections freezing.  Now you can telnet out for as long as you 
want.

X also works.  Displaying remotely to your native X server probably has worked 
for a long time.  You can also run X locally.  Use Xnest displaying to your 
native server as the local X server and have your X apps display to :0.

				Jeff