From: Jeff D. <jd...@ka...> - 2001-08-29 18:25:20
|
um...@os... said: > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > Sorry, no help available for this option yet. > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > Sorry, no help available for this option yet. > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > Sorry, no help available for this option yet. How is your script driving oldconfig? It looks pretty broken wrt new options. > If you want a script to build rpms properly, you need to distribute a > proper working configuration. I'm trying to use the one in arch/um/ > config.release So turn on CONFIG_UML_NET_TUNTAP with xconfig or something and move that config to config.release. This bug isn't that hard to work around. Jeff |
From: Jeff D. <jd...@ka...> - 2001-08-30 16:14:11
|
um...@os... said: > The point is that the config I use is the one YOU distribute, > If you distribute the one that corresponds to the binaries you distribute, > then my script will produce an RPM the contains the same (as near as we can > do it with different compilers/libraries) binary. When you're experimenting with it and getting it to work nicely, you can bend the rules a little once in a while. So, at this point, I don't see the problem with fiddling the config if the build breaks. And I still think whatever you have driving oldconfig is broken... Jeff |
From: Michael R. <mc...@sa...> - 2001-09-05 20:23:03
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jeff" == Jeff Dike <jd...@ka...> writes: Jeff> This update features a TUN/TAP backend for the network driver. Jeff> To use it, you: Jeff> Make sure the host has TUN/TAP, compiled in, as an autoloaded modules, or Jeff> as an already loaded modules, and /dev/net/tun looks like this Jeff> crw-r--r-- 1 root root 10, 200 Jul 20 15:24 tun Jeff> Turn on CONFIG_UML_NET_TUNTAP Jeff> Grab the latest uml_net if you don't want to be responsible for doing host Jeff> setup, and make it look like this: Jeff> -rwsr-xr-x 1 root root 67902 Aug 28 13:38 /usr/bin/uml_net Forgive my ignorance, but how does this differ from the other networking options? It uses TUNTAP instead of ethertap? What advantages are there. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO5aFdoqHRg3pndX9AQHF8gQAkvBBzAyM0VRcK0ljgRtVB1yct1NxATOq 3aEDDIqMrvLAK9K1spL8b+1z6keSputcmb3RaflqfAWf6vkrhWR8nYq3aU7BYfLw Kn2eqs+736TigOD4DdQk5rRtwLUKcfiOstuPI4MBk/d4hBinvhcDAdT0xqM4sLzu PAPoxChqf8E= =DNBG -----END PGP SIGNATURE----- |
From: Jeff D. <jd...@ka...> - 2001-09-05 21:01:09
|
mc...@sa... said: > Forgive my ignorance, but how does this differ from the other > networking options? > It uses TUNTAP instead of ethertap? Yup. > What advantages are there. People running 2.4 get upset when they look up ethertap in Documentation/networking and they see the word "deprecated". It's faster, at least because UML gets to send packets straight to the device instead of using uml_net as an intermediary as with ethertap. Yon Uriarte also reported that even going through uml_net, TUN/TAP was faster than ethertap. TUN/TAP respects the file permissions on the device, so if it's made persistent, the sysadmin can give you a device by chowning it to you, and you can use it without any sort of root help. Jeff |
From: JS <um...@os...> - 2001-08-30 15:01:41
|
On Thu, 30 Aug 2001 02:34, you wrote: > um...@os... said: > > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > > Sorry, no help available for this option yet. > > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > > Sorry, no help available for this option yet. > > TUN/TAP transport (CONFIG_UML_NET_TUNTAP) [N/y/?] (NEW) > > Sorry, no help available for this option yet. > > How is your script driving oldconfig? It looks pretty broken wrt new > options. See next para > > > If you want a script to build rpms properly, you need to distribute a > > proper working configuration. I'm trying to use the one in arch/um/ > > config.release > > So turn on CONFIG_UML_NET_TUNTAP with xconfig or something and move tha= t > config to config.release. This bug isn't that hard to work around. The point is that the config I use is the one YOU distribute, If you distribute the one that corresponds to the binaries you distribute= ,=20 then my script will produce an RPM the contains the same (as near as we c= an=20 do it with different compilers/libraries) binary. When I'm satisified that I have no errors in the script then I can releas= e it=20 for you (and anyone else) to use. |