user-mode-linux-devel

Re: [User-mode-linux-devel] UML/PPC status

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

> > execute_syscall is now in sys-*, rather than kernel/syscall_kern.c.

> That's a bit of a shame - most of the code is fine for PPC too, except
> for the cases dealing with i386-only syscalls.  I'd personally prefer
> to have an #ifdef or two rather than copying most of it verbatim for
> the other architecture(s). 

I just looked at the gcc docs and it turns out there's a syntax for 
initializing arrays that lets you explicitly specify indexes:
	int a[6] = { [4] 29, [2] = 15 };

So, for now, write your own execute_syscall.  I'll rework it into something 
which has a syscall table that says things like:
	{ [__NR_exit] sys_exit,
	  [__NR_fork] sys_fork,
	  ...
          ARCH_SYSCALLS }

And the i386 ARCH_SYSCALLS would have 
	[__NR_vm86] sys_ni,
	...
and all the others that don't exist on ppc.

And yours would have whatever things are different on ppc.

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

On Wed, 3 May 2000, Jeff Dike wrote:

> I think I mentioned in one of my various pieces of mail that I'm
> going to change it to UM_EXEC_INIT(pid) (I just made up the name
> right now though...).

Ok, fine.

> > Incidentally, it looks like the current system I have is falling
> > over inside padzero() from the elf loading stuff.  I suppose that
> > means the bss hasn't been mapped properly.
> 
> That's supposed to get a segfault.  The fault handler is supposed to
> map in the page properly.

Hmm...  I'll have to have a closer look.  At the moment all that I see
is a zombie process.  It'd be nice if the kernel shut down when init
dies - I've been running 'killall -KILL linux' a lot recently.  I may
have missed something obvious, of course.

Incidentally, have you got gdb usefully debugging this sort of thing?
I haven't had all that much luck, presumably due either to the funky
remapping or the multiple threads.

> When you exec, there are going to be three segfaults before the
> process actually gets going - the stack, padzero filling out bss,
> and the entry point.  So the segfault handler is going to map those
> three pages in before anything else happens.

Is padzero the first one to happen?  If not, it's possibly even
stranger.

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/PPC status

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

> Ok.  It's possible that that sequence of ptrace calls may need to be
> separated out, since the PPC stuff may need to set several more
> registers than i386.

I think I mentioned in one of my various pieces of mail that I'm going to 
change it to UM_EXEC_INIT(pid) (I just made up the name right now though...).  
That gives i386 the info it needs.  If ppc needs to zero out a bunch of 
registers, you can define it as
	({ ptrace(PTRACE_POKEUSER, pid, reg1, 0);
	   ptrace(PTRACE_POKEUSER, pid, reg2, 0);
	   ...
	   0; })

> I don't know how much of that is handled by the exec code outside of
> arch/um, and how much is actually supposed to be done by your code.

Any low-level stuff like setting up registers is done in the arch layer.  The 
address space and everything else is set up by the upper layers.

> Incidentally, it looks like the current system I have is falling over
> inside padzero() from the elf loading stuff.  I suppose that means the
> bss hasn't been mapped properly. 

That's supposed to get a segfault.  The fault handler is supposed to map in 
the page properly.  When you exec, there are going to be three segfaults 
before the process actually gets going - the stack, padzero filling out bss, 
and the entry point.  So the segfault handler is going to map those three 
pages in before anything else happens.

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

On Mon, 1 May 2000, Jeff Dike wrote:

[snip]
> > There's one reference to EDX in finish_exec() - what's that one
> > for?
> 
> You need to worry about this one.  Elf binaries take a value in EDI
> (on i386) which is an address of an initialization procedure or
> something.  Linux doesn't use it, so it goes in as zero.  Look
> through asm-ppc/*elf*.h for something similar.

There doesn't seem to be anything similar.  There's a comment
somewhere saying that i386 takes a pointer to a function to call on
exit in EDX, and not mentioning other architectures.

Do you know of a good online reference for Elf things like this?

> >  I've deleted a large chunk of arch/um/kernel/syscall_kern.c for
> > system calls which don't seem to exist on PPC.
> 
> This sucks.

Indeed.  I now have an #ifdef.  I think it'd be useful to define a
symbol like __UM_$(SUBARCH)__ or something similar for this sort of
thing.  At least some of the syscalls there will be i386 only, rather
than just non-ppc (vm86 springs to mind).

> > +#define UM_SP_OFFSET UESP 
> > +#define UM_IP_OFFSET EIP 
>
> These are wrong, and I bet the ppc equivalents you've got are wrong,
> too.

Yes, you're absolutely right...  brain failure on my part.

> I would prefer that you have your Makefile make links to arch/ppc
> files that you're just going to steal whole.  That keeps the patch
> size down, and gives this kernel the benefit of whatever changes are
> made in those files in the future.

I've done that for bitops.c.  The assembler functions are trickier,
as they seem to need quite a bit of the environment from arch/ppc.
I'll look into it.

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/PPC status

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

I put in most of those changes.  The exceptions are things that I don't want, 
or don't understand :-)

A couple of comments:

arch/um/include/sysdep-ppc/ptrace.h - At some point, we should see if the 
stuff you copied from asm-ppc/ptrace.h can be had by #including it and 
undefining stuff that's not needed.

arch/um/sys-ppc/bitops.c and arch/um/sys-ppc/checksum.S - just make them 
links, like my checksum.S.

I've moved the arch/um/kernel symlinks into sys-i386.
execute_syscall is now in sys-*, rather than kernel/syscall_kern.c.

I've defined UM_ELF_ZERO_OFFSET which is the ptrace offset of whatever 
register needs to be zeroed.

My latest diffs are attached.

				Jeff

Re: [User-mode-linux-devel] IRQ handling

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

jl...@mi... said:
> I would like to propose adding interrupt handling to the UM kernel.

Are you volunteering to do it, or just saying it would be a good thing?

> [ much snippage with which I agree ]

> Any comments? 

Yeah.  I never said that interrupts were never going to happen.  They're just 
something I haven't gotten around to yet.  I add stuff when I miss it.  And I 
don't really miss real interrupts.  The timer handles everything.  That hurts 
latency, since the timer only happens every 50ms, but you don't really notice 
that too much.

That being said, my thinking on interrupts is that we should probably use 
SIGIO as the hardware interrupt.  I think there are some subtleties on where 
SIGIO gets delivered.  You'd have to make sure that it gets delivered to the 
process that's currently running and not to a stopped process.  There's also a 
race to be careful of when input happens as a context switch is happening.  
You need to make sure that SIGIO doesn't get delivered to a process that has 
just been stopped.  I don't think that's a big deal, you just need to be a 
little careful.

With SMP, we'd need to find a mechanism to round-robin the interrupts around 
to the different running processes.  I have no idea how that would work.

I don't think there's any magic here.  It might not even be that hard to do.  

				Jeff

[User-mode-linux-devel] IRQ handling

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

Jeff,

I know last time I mentioned this you pointed me to how you are currently
getting around IRQ handling.

I would like to propose adding interrupt handling to the UM kernel.  Being that
UM is an attempt to provide a exvironment to developers that mimics the Linux
kernel as close a possible (yet maintaining the level of protection provided
by running in userland) we should try to make the implementation of emulated
hardware as similar to a native kernel as possible.  Currently anytime input
is coming from outside of the UM it is received by a UM stub which then makes a
call into the UM kernel via a UM kernel function.  In the native Linux kernel
this type of activity is done via system calls (from the userland) and
interrupts (from the hardware).  Jeff has done a great job of keeping the
system call path as similar to a native kernel as possible.  This is good
because a developer can realistically implement a new system call, and only
needs to take into account a couple of UM related issue, but other then that
the system call implementation should portable over to any plateform (with
minimal plateform specific gunk).  I think we can do the same think for
interrupts.  By using an interrupt based environament we now force developers
to respect IRQ masking and the fact that IRQs can spring up at any time.  This
will provide developers a more realistc environemt to test new software.  
ranted a developer will not be able to write a hardware driver in a UM and
them magically have it work on a native kernel, but a file system developer will
be forced to deal with interrupts even when developing in the UM.  So in
theory the UM implementation of a file system can be directly ported to a
native kernel.

If we do add interrupt handling, we can take it a step further and provide
useful debugging of interrupt handling.  We could write logging routins that
tell when and where interrupts occured, and using this the developer can
figure out where to mask interrupts.

Any comments?
Jim

-- 
James R. Leu

Re: [User-mode-linux-devel] UML/PPC status

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

> I've now merged my changes in and have a kernel which goes as far as
> mounting the root filesystem, although I haven't managed to run an
> init yet.  The patch is attached.  It will break i386 in its current
> state, unfortunately.

Great.  I'm going to go through it and merge in the things that don't break my 
pool.

> There were some leftover references to Intel registers around.  I've
> added a couple more defines for them. 

I fixed these.

> There's one reference to EDX in finish_exec() - what's that one for?

You need to worry about this one.  Elf binaries take a value in EDI (on i386) 
which is an address of an initialization procedure or something.  Linux 
doesn't use it, so it goes in as zero.  Look through asm-ppc/*elf*.h for 
something similar.

>  I've deleted a large chunk of arch/um/kernel/syscall_kern.c for
> system calls which don't seem to exist on PPC.

This sucks.

> There are some references to CR2, which does map to a PPC register
> (DAR I think) of a different name.  I think they could be renamed to
> something more generic.

True.

> +#define UM_SP_OFFSET UESP 
> +#define UM_IP_OFFSET EIP 

These are wrong, and I bet the ppc equivalents you've got are wrong, too.  
These are byte offsets so they need to be multiplied by the register length.
I.e. #define UM_IP_OFFSET (EIP * sizeof(long))
That might be hurting your attempts to exec init.

I would prefer that you have your Makefile make links to arch/ppc files that 
you're just going to steal whole.  That keeps the patch size down, and gives 
this kernel the benefit of whatever changes are made in those files in the 
future.

On the whole, those changes look fairly clean.

				Jeff

[User-mode-linux-devel] Portability changes are in CVS

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

Most of them anyway.  There's a bit in exec_user.c referring to EDI still.  I 
need to know what the ppc requirements for initializing registers for elf 
binaries are before I can tell what to do about that.

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

On Mon, 1 May 2000, Jeff Dike wrote:

> Attached are diffs which abstract away a lot of the arch-dependent stuff:

Good stuff - I've now merged my changes in and have a kernel which
goes as far as mounting the root filesystem, although I haven't
managed to run an init yet.  The patch is attached.  It will break
i386 in its current state, unfortunately.

[snip]
> I think this covers most of the problems that you've told us about so far.

It does cover most things.

> Let me know what else you find.

There were a few things...

There were some leftover references to Intel registers around.  I've
added a couple more defines for them.  There's one reference to EDX in
finish_exec() - what's that one for?  My patch changes it to an PPC
register, but I don't really know which one it should be.  (This is
one of the places which will break i386)

Although the arch is "ppc", some places need "powerpc", eg the
-U__powerpc__ option and link.ld.in.  There may need to be an extra
level of indirection for that.  I covered the former with
Makefile-ppc, but for the latter I just edited the link.ld.

A few places have actual #ifdef __UM_PPC__ (a define I've added)
blocks.  Another place should have but doesn't - I've deleted a large
chunk of arch/um/kernel/syscall_kern.c for system calls which don't
seem to exist on PPC.  Oops.  I'm not going to fix it now, as it's 3am
and I've got work tomorrow, but I'll put the stuff back in with an
#ifdef tomorrow if no-one beats me to it.

The ppc version of [_]switch_to has a different number of arguments -
I've hacked around it with some preprocessor macros in
<asm-um/system.h>.  I've done something similar for struct sigcontext,
which is called struct sigcontext_struct in ppc.

There are some references to CR2, which does map to a PPC register
(DAR I think) of a different name.  I think they could be renamed to
something more generic.

> The kernel should get past the UNIFIX thing once remap_data works.

Correct.  :-)

> You'll need to define the entry point as 0x20000000 to avoid being
> stomped on by init when you get around to execing it.

I've done that, although something is still broken.

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/PPC status

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

Attached are diffs which abstract away a lot of the arch-dependent stuff:

the Makefile calculates SUBARCH
other gratuitous mentions of i386 in the Makefile are gone
there is now support for Makefile-$(SUBARCH), which for now just specifies an 
entry point
there is support for arch/um/include/sysdep which points to 
arch/um/include/sysdep-$(SUBARCH), which contains arch-dependent stuff that 
can be used by both user and kernel code.  Currently, this includes just 
ptrace.h.
arch-dependent C code goes in arch/um/sys-$(SUBARCH).  This directory is 
expected to produce a sys.o.
mentions of i386 have been removed from the link script
ports are expected to define a struct sys_pt_regs in 
arch/um/include/sysdep/ptrace.h, as well as a bunch of generic macros like 
UM_SP and UM_SYSCALL_RET
currently, ports need to write up 4 procedures, 2 to convert between struct 
sys_pt_regs and struct sigcontext, and the ptrace putregs and getregs functions
remap_data is now portable, I hope
I haven't done anything about the files that just get linked to from 
arch/i386/kernel.  Those I'll probably move into arch/um/sys-i386.

I think this covers most of the problems that you've told us about so far.

Let me know what else you find.

The kernel should get past the UNIFIX thing once remap_data works.  That's 
when the kernel tries to start up the init thread.  If remap_data didn't work, 
that doesn't work.

You'll need to define the entry point as 0x20000000 to avoid being stomped on 
by init when you get around to execing it.

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

On Mon, 1 May 2000, Jeff Dike wrote:

> > 0fee8000-0ffc9000 r-xp 00000000 03:09 120950     /lib/libc-2.1.3.so
> > 0ffc9000-0ffd8000 ---p 000e1000 03:09 120950     /lib/libc-2.1.3.so
> > 0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950     /lib/libc-2.1.3.so 
> 
> These are more like what I'd expect.  Except that "---p", that's pretty 
> strange.

Yes, 'tis a bit.  The offset 000e1000 puts it in the .data section of
the library, I think.

> The ls permissions:
> > 10000000-1000c000 r-xp 00000000 03:09 30304      /bin/ls
> > 1001b000-1001d000 rwxp 0000b000 03:09 30304      /bin/ls 
> are still a bit different.  It still looks like just text, data, stack, with 
> no separate bss.



> Where do binaries typically load on ppc?  Is ls typical, loading at
> 0x10000000?  If so, we're going to have to move linux higher, like
> to 0x20000000.

That does seem to be typical, although there are a few exceptions
(mostly kernel threads).

> > Do you want to do that?  :-)
> 
> I'm in the process of doing that.

Cool.

> What I've done so far is get rid of the i386 stuff from the build,
> and move the ptrace and register stuff into separate directories.
> So, you'll be able to just do the ppc equivalent of the i386 stuff,
> and it ought to work.

Looking forward to it!

> What's the ppc page size?

It's 4k, same as i386.

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/PPC status

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

> 0fee8000-0ffc9000 r-xp 00000000 03:09 120950     /lib/libc-2.1.3.so
> 0ffc9000-0ffd8000 ---p 000e1000 03:09 120950     /lib/libc-2.1.3.so
> 0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950     /lib/libc-2.1.3.so 

These are more like what I'd expect.  Except that "---p", that's pretty 
strange.

The ls permissions:
> 10000000-1000c000 r-xp 00000000 03:09 30304      /bin/ls
> 1001b000-1001d000 rwxp 0000b000 03:09 30304      /bin/ls 
are still a bit different.  It still looks like just text, data, stack, with 
no separate bss.

Where do binaries typically load on ppc?  Is ls typical, loading at 
0x10000000?  If so, we're going to have to move linux higher, like to 
0x20000000.

> Do you want to do that?  :-)

I'm in the process of doing that.

What I've done so far is get rid of the i386 stuff from the build, and move 
the ptrace and register stuff into separate directories.  So, you'll be able 
to just do the ppc equivalent of the i386 stuff, and it ought to work.

What's the ppc page size?

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

On Mon, 1 May 2000, Jeff Dike wrote:

> What's going on here is that the kernel is copying its data and bss into two 
> files, unmapping them, and then mapping those files shared in their places.  
> This is to make the kernel data shared across forks.  Otherwise, they would 
> end up copy-on-write.

Ok, that makes sense.

> remap_data recognizes the appropriate maps by their permissions.  It
> looks like another method is needed for ppc.
> 
> It looks like there is no separate text and data in the maps.  Just
> text, bss, and stack.  Is that right?

It may be something odd about the linux binary.  The maps from /bin/ls
look a bit more interesting.  One difference is the dynamic linking -
linux seems to be static.

0fee8000-0ffc9000 r-xp 00000000 03:09 120950     /lib/libc-2.1.3.so
0ffc9000-0ffd8000 ---p 000e1000 03:09 120950     /lib/libc-2.1.3.so
0ffd8000-0ffeb000 rwxp 000e0000 03:09 120950     /lib/libc-2.1.3.so
0ffeb000-0fff0000 rwxp 00000000 00:00 0
10000000-1000c000 r-xp 00000000 03:09 30304      /bin/ls
1001b000-1001d000 rwxp 0000b000 03:09 30304      /bin/ls
30000000-30014000 r-xp 00000000 03:09 120833     /lib/ld-2.1.3.so
30014000-30015000 rw-p 00000000 00:00 0
30023000-30027000 rwxp 00013000 03:09 120833     /lib/ld-2.1.3.so
7fffe000-80000000 rwxp fffff000 00:00 0

> Why don't we just ditch the permissions comparisons and use _etext
> and _end.  The region between _etext and _end is the data, so just
> fiddle remap_data to remap that.

Do you want to do that?  :-)

> > Is something actually wrong here, or should it only exit if both
> > remap_data("rwx") and remap_data("rw-") fail? 
> They both have to succeed.

Ok.

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/PPC status

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

> The first time I ran it it exited from remap_data("rw-") saying
> "remap_data couldn't find data segment" because there were no entries
> in /proc/self/maps with those permissions:

> 10000000-1016a000 rwxp 00000000 03:0d 339044 /home/cme20/working/umlinux/linux/linux 
> 1016a000-1019f000 rwxp 00000000 00:00 0
> 7ffff000-80000000 rwxp 00000000 00:00 0 

What's going on here is that the kernel is copying its data and bss into two 
files, unmapping them, and then mapping those files shared in their places.  
This is to make the kernel data shared across forks.  Otherwise, they would 
end up copy-on-write.

remap_data recognizes the appropriate maps by their permissions.  It looks 
like another method is needed for ppc.

It looks like there is no separate text and data in the maps.  Just text, bss, 
and stack.  Is that right?

Why don't we just ditch the permissions comparisons and use _etext and _end.  
The region between _etext and _end is the data, so just fiddle remap_data to 
remap that.

> Is something actually wrong here, or should it only exit if both
> remap_data("rwx") and remap_data("rw-") fail? 
They both have to succeed.

Those permissions are pretty wierd.  Does ppc not have the same kind of page 
protections that x86 does?

				Jeff

[User-mode-linux-devel] UML/PPC status

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

I've now got as far as linking the executable under PPC linux,
basically by copying bits from arch/ppc until it stopped having
unresolved symbols.

The first time I ran it it exited from remap_data("rw-") saying
"remap_data couldn't find data segment" because there were no entries
in /proc/self/maps with those permissions:

10000000-1016a000 rwxp 00000000 03:0d 339044 /home/cme20/working/umlinux/linux/linux
1016a000-1019f000 rwxp 00000000 00:00 0
7ffff000-80000000 rwxp 00000000 00:00 0

Is something actually wrong here, or should it only exit if both
remap_data("rwx") and remap_data("rw-") fail?

After commenting out the "exit(1)" line it gets as far as saying
"POSIX conformance testing by UNIFIX" and then seems to be spinning in
the tracing thread.  I haven't looked at what it's trying to do yet.

I hope to get around to building a patch later today.

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

[User-mode-linux-devel] uml-net-0.001

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

I have made some fixes to uml-net.  I thought I should give these
version numbers so I can keep track of what I'm doing :-)

Yesterdays patch is version 0.000 todays is 0.001.

The fixes:
- 'uml-net' now can connect to a physical ethernet and make it a member of
  one of the broadcast domains.  It can handle multi phys interfaces.

  Example:  uml-net eth0 100 eth1 101

  Copies packet to/from broadcast domain 100 and the hosts eth0
  and copies packet to/from broadcast domain 101 and the hosts eth1
- 'uml-net' now backgrounds itself automagically
- the 'kernel' driver now filters based on MAC addresses correctly
  in theory multicast should work now as well.
- the 'kernel' side of the kernel driver now supplies the user side the
  sockaddr to use when connecting to the 'uml-net' process.  An ioctl was
  added so the user (in a UML) can set this data as well.  The purpose is so
  the user can have multi host machines with UMLs that share broadcast
  domains. (I still  haven't written the user program for this yet)
- if you kill the 'uml-net' process you will still kill the UML.  I'm trying
  to figire out why.

-- 
James R. Leu

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

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

On Sun, Apr 30, 2000 at 10:13:14PM -0400, Gerald Britton wrote:
> > I don't see an easy way for the ethertap-based virtual network to operate in
> > a host routed network. F.e. the host acts as the gateway to the uml private
> > network and provides firewall services (IP MASQ).
> 
> The way all this would work, the virtual net would look just like an ethernet
> to both the host system (as network interface tap0) and to the virtual systems
> (as network interface eth0) ... these can be treated as any other ethernet
> and if the host machine has an uplink connection, it can route between them.

By attaching to eth0 with a PF_PACKET socket you do not even need to configure
bridging on the host system.  I have that working right now, in fact, I'm
telnet'ed out of a uml right now :-)

I'm trying to get the tap0 to work as well.  I figure that can be used to
to implement the host system acting as a router (or firewall).

> If the host has an ethernet connection, the host can either route between the
> two, or it can setup bridging between the two networks so they seem to be one
> larger ethernet.  This allows arbitrary firewalling to be potentially setup
> between the real network and the virtual network, or it allows for the virtual
> network to act as if it were directly part of the real network.
> 
> 				-- Gerald

-- 
James R. Leu

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

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

> I don't see an easy way for the ethertap-based virtual network to operate in
> a host routed network. F.e. the host acts as the gateway to the uml private
> network and provides firewall services (IP MASQ).

The way all this would work, the virtual net would look just like an ethernet
to both the host system (as network interface tap0) and to the virtual systems
(as network interface eth0) ... these can be treated as any other ethernet
and if the host machine has an uplink connection, it can route between them.

If the host has an ethernet connection, the host can either route between the
two, or it can setup bridging between the two networks so they seem to be one
larger ethernet.  This allows arbitrary firewalling to be potentially setup
between the real network and the virtual network, or it allows for the virtual
network to act as if it were directly part of the real network.

				-- Gerald

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

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

> I don't see an easy way for the ethertap-based virtual network to
> operate in a host routed network. F.e. the host acts as the gateway to
> the uml private network and provides firewall services (IP MASQ). 

When the virtual net is sucking packets more or less straight off the 
ethernet, the host has no chance to do firewalling or masquerading, is that it?

That sounds like a good argument not to even switch the umn driver from slip 
to ethertap.

If we have a ethertap-based virtual net and a slip-based point-to-point 
connection to the host, does that leave any functional holes, like 
masquerading non-ip protocols?

				Jeff

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

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

On Sun, Apr 30, 2000 at 03:37:41PM -0500, Jeff Dike wrote:
> gbr...@mi... said:
> > It isn't going to endup being any changes to the virtual ethernet
> > driver to make my idea work, the userland daemon acting as the virtual
> > network would simply have another connection to it connected to the
> > ethertap.
> 
> Ok.  I think I can buy this.
> 
> > SLIP was designed to only carry IP over the serial link, this is one
> > of the major reasons PPP came about as it can carry mostly arbitrary
> > protocols. 
> 
> Should we consider that the ethertap-based virtual network obsoletes the 
> existing umn driver?  Or are there things that an ethertap-based umn would be 
> good for that the virtual network wouldn't?

I don't see an easy way for the ethertap-based virtual network to operate in
a host routed network. F.e. the host acts as the gateway to the uml private
network and provides firewall services (IP MASQ).

Jim

> 
> 				Jeff
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel

-- 
James R. Leu

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

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

is...@ne... said:
> 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.

Oops.  I'll fix that as soon as sourceforge lets me log in again.

> I guess this information is wrong for RedHat distributions?

No.  It's just plain wrong.

				Jeff

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

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

gbr...@mi... said:
> It isn't going to endup being any changes to the virtual ethernet
> driver to make my idea work, the userland daemon acting as the virtual
> network would simply have another connection to it connected to the
> ethertap.

Ok.  I think I can buy this.

> SLIP was designed to only carry IP over the serial link, this is one
> of the major reasons PPP came about as it can carry mostly arbitrary
> protocols. 

Should we consider that the ethertap-based virtual network obsoletes the 
existing umn driver?  Or are there things that an ethertap-based umn would be 
good for that the virtual network wouldn't?

				Jeff

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

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

On Sun, Apr 30, 2000 at 01:36:53PM -0500, Jeff Dike wrote:
> That's a real good reason to switch to ethertap, but I'd still like to know 
> what about slip makes it impossible to encapsulate things like appletalk.

SLIP was designed to only carry IP over the serial link, this is one of the
major reasons PPP came about as it can carry mostly arbitrary protocols.

> > 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.
> 
> You'd make one uml the gateway to the outside world, give it a connection to 
> the host, and set up routes on the others to it.

Yes, that's pretty much what you'd have to do, and it would require setting
up routing and subnetting which potentially wouldn't be possible on the
network.

> I agree that that's pretty slick.  Would all the packets on the ethernet flow 
> through the bridge?  If so, I think that would make it look like all the umls 
> really were on the physical ethernet.

Yes, it would.  It's also possible to make the bridge filter so that it acts
more like switched ethernet and would only pass broadcasts and packets
destined for the other side of the bridge.

> The problem I have is the combining of virtually networking umls and 
> connecting them to the host.  Those seem to me to belong in separate drivers.
> 
> On a physical machine, if you have a local ethernet and a connection to an 
> outside network, those are different devices and probably different drivers.

My ethernet is my connection to the outside world, and has been for years.

> Without a good reason to put them in the same driver, I'd like to mimic the 
> physical world as much as possible.

It isn't going to endup being any changes to the virtual ethernet driver to
make my idea work, the userland daemon acting as the virtual network would
simply have another connection to it connected to the ethertap.  I haven't
taken a look at the uml-net program, but if it works as I suspect it does,
it wouldn't actually require modification to it, just a separate program to
connect between it and the ethertap (or an interface to an AF_PACKET system
for doing bridging).

				-- Gerald

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

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

gbr...@mi... said:
> This doesn't actually work for protocols other than IP.  You can't
> send such things as AppleTalk over the SLIP link. 

Why not?

That's a real good reason to switch to ethertap, but I'd still like to know 
what about slip makes it impossible to encapsulate things like appletalk.

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

But if it were possible to pass arbitrary protocols over slip, you don't care 
whether or not you can pass ethernet frames over it.

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

You'd make one uml the gateway to the outside world, give it a connection to 
the host, and set up routes on the others to it.

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

I agree that that's pretty slick.  Would all the packets on the ethernet flow 
through the bridge?  If so, I think that would make it look like all the umls 
really were on the physical ethernet.

The problem I have is the combining of virtually networking umls and 
connecting them to the host.  Those seem to me to belong in separate drivers.

On a physical machine, if you have a local ethernet and a connection to an 
outside network, those are different devices and probably different drivers.

Without a good reason to put them in the same driver, I'd like to mimic the 
physical world as much as possible.

				Jeff