Menu
▾
▴
user-mode-linux-devel
|
From: James R. L. <jl...@mi...> - 2000-04-29 19:56:32
Attachments:
uml.diff
|
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 |
|
From: Gerald B. <gbr...@mi...> - 2000-04-29 20:11:01
|
> 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 |
|
From: James R. L. <jl...@mi...> - 2000-04-29 20:25:20
|
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 |
|
From: Jeff D. <jd...@ka...> - 2000-04-30 04:24:30
|
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 |
|
From: Gerald B. <gbr...@mi...> - 2000-04-30 05:26:44
|
> > 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 |
|
From: Jeff D. <jd...@ka...> - 2000-04-30 13:34:00
|
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 |
|
From: Gerald B. <gbr...@mi...> - 2000-04-30 17:20:54
|
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 |
|
From: Jeff D. <jd...@ka...> - 2000-04-30 17:42:46
|
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 |
|
From: Gerald B. <gbr...@mi...> - 2000-04-30 18:09:59
|
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 |
|
From: Jeff D. <jd...@ka...> - 2000-04-30 19:43:45
|
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 |
|
From: James R. L. <jl...@mi...> - 2000-04-30 19:58:21
|
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 |
|
From: Gerald B. <gbr...@mi...> - 2000-05-01 02:21:45
|
> 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 |
|
From: James R. L. <jl...@mi...> - 2000-05-01 02:56:06
|
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 |
|
From: <is...@ne...> - 2000-04-30 06:42:27
Attachments:
patch_redhat6
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X