| --- | Log | opened Wed Mar 12 00:00:49 2008 |
| 03:45 | <unlink:#uml> | whenever i specify eth0= anything on the kernel command line, i'm getting high eth numbers, like eth6 or eth7 |
| 03:56 | <Magotari:#uml> | Yeah, that will happen. |
| 03:56 | <Magotari:#uml> | See, some distros check for the mac addy. |
| 03:56 | <Magotari:#uml> | If you specify a mac with your eth0= line, it will stay the same. |
| 03:57 | <Magotari:#uml> | The one distro I know does this is slackware, but I'm sure there are more. |
| 04:02 | <unlink:#uml> | yeah, just got that |
| 04:02 | <unlink:#uml> | as a matter of fact |
| 04:03 | <unlink:#uml> | when i looked at my /etc/udev/rules.d/70_persistent-net.rules |
| 04:03 | <Magotari:#uml> | Yeah. That is the file. |
| 04:04 | <unlink:#uml> | i noticed it had 29081528 different mac addresses in it, presumably randomly numbered by linux. now i'm just specifying the whole line in the eth0= param. |
| 04:06 | <unlink:#uml> | the ubuntu gutsy install CDs work terribly with user mode linux, unfortunately |
| 04:06 | <unlink:#uml> | it can't detect the CD in the installer. i just gave up and did my initial install with qemu |
| 04:11 | <Magotari:#uml> | That is how I always do them. Can't be bothered to do it the right way. |
| 04:12 | <unlink:#uml> | i don't plan on ever doing it again -- it's too slow. i'm just going to reuse a tarred up install and unpack it in a fresh filesystem (after changing the UUIDs in /etc/fstab *grr*) |
| 04:13 | <Magotari:#uml> | Ubuntu in general can cause trouble to UML, at least that was the track record for a while. |
| 04:13 | <Magotari:#uml> | Did you try kqemu? |
| 04:13 | <Magotari:#uml> | It can make speeds bearable. |
| 04:13 | <unlink:#uml> | no, i'm not interested in compiling kernel modules |
| 04:13 | <unlink:#uml> | it's not packaged in gutsy |
| 04:13 | <Magotari:#uml> | Right. |
| 04:14 | <unlink:#uml> | although it is packaged in etch, IIRC |
| 04:15 | <unlink:#uml> | we're moving from etch to gutsy because etch is just so out of date :\ |
| 04:15 | <unlink:#uml> | (backports.org doesn't have the packages we want) |
| 04:15 | <Magotari:#uml> | Have you pondered non-debian distros? Arch is pretty good. Even Fedora ain't too bad. |
| 04:16 | <Magotari:#uml> | Slackware tends to make a good virtual machine as well, quite a light system. |
| 04:17 | <unlink:#uml> | i have extensive experience with slackware. it just doesn't have enough packages. the overhead of maintaining slackware packages is just too high. |
| 04:17 | <unlink:#uml> | never used arch. i used FC3 and FC5. unless they've completely reworked RPM and yum, i'm not going back |
| 04:18 | <unlink:#uml> | dpkg and apt may have their shortcomings, but they are the most correct, robust package management tools that i've ever seen, which is very important for this critical tool |
| 04:26 | <Magotari:#uml> | I used to be a huge fan of Gentoo, but recently they have gone to hell a little bit. |
| 04:26 | <Magotari:#uml> | Emerge is fantastic. I find debian severely outdated, rolling updates being my kind of thing. |
| 04:26 | <Magotari:#uml> | Of course Gentoo makes the worst virtual machine ever. |
| 04:27 | <Magotari:#uml> | Unless you precompile it beforehand. |
| 04:41 | <unlink:#uml> | gentoo lacks in QA as well |
| 07:59 | <caker:#uml> | users == QA |
| 07:59 | * | caker:#uml runs |
| 09:09 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 09:19 | <Supaplex:#uml> | haha caker :) |
| 09:36 | -!- | dang [~dang@aa-redwall.ghs.com] has quit [Quit: Leaving.] |
| 09:45 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 10:16 | <Magotari:#uml> | Wow. Two days straight spent on coding myco. And finally it seems like it all may work out. Of course, being written in common lisp, kinda hard to use for anyone. I hope it will translate to C with some translator... |
| 10:38 | -!- | Magotari [~karol@chello089076074249.chello.pl] has quit [Quit: Lost terminal] |
| 10:41 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has joined #uml |
| 10:42 | <jdike:#uml> | Hi guys |
| 10:44 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has joined #uml |
| 10:44 | -!- | Magotari [~karol@chello089076074249.chello.pl] has joined #uml |
| 11:18 | -!- | kokoko1 [~Slacker@203.148.64.252] has joined #uml |
| 11:18 | <kokoko1:#uml> | Hiya |
| 12:15 | <jdike:#uml> | back to beating on vcpu |
| 12:44 | <jdike:#uml> | so, vcpu gets me up to ~86% of native on a kernel build |
| 13:04 | <Magotari:#uml> | Woah. Seriously nice. |
| 13:14 | -!- | kokoko1 [~Slacker@203.148.64.252] has quit [Ping timeout: 480 seconds] |
| 13:18 | <caker:#uml> | jdike: nice |
| 13:18 | <caker:#uml> | is that one vcpu in the guest and comparing make -j1 ? |
| 13:19 | <jdike:#uml> | -j 3 |
| 13:19 | <caker:#uml> | with how many cpus on the host and assigned to the UML? |
| 13:19 | <jdike:#uml> | 1 |
| 13:20 | <caker:#uml> | that |
| 13:20 | <caker:#uml> | .. |
| 13:21 | <caker:#uml> | that's wild -- so, somehow implementing vcpus breaks through a bottleneck that exists with the "old" way |
| 13:21 | <jdike:#uml> | a bottleneck? |
| 13:21 | <jdike:#uml> | it's just another performance improvement |
| 13:23 | <caker:#uml> | my thinking is that a single processor vcpu UML and an older UML kernel (without vcpu support) would have the same kernel build times |
| 13:24 | <jdike:#uml> | do you know what vcpu is? |
| 13:24 | <caker:#uml> | hehe, I guess not -- I figured it was virtual cpu support for UML guests (smp) |
| 13:25 | <jdike:#uml> | Oh no |
| 13:25 | <jdike:#uml> | SMP requires nothing special on the host |
| 13:25 | <jdike:#uml> | vcpu allows a process to intercept its own system calls and signals |
| 13:26 | <jdike:#uml> | you say vcpu(mm_fd, &egs-and-other-crud-struct) |
| 13:26 | <jdike:#uml> | and the process starts executing in the mm_fd address space with the registers given |
| 13:27 | <jdike:#uml> | until it receives a signal or makes a system call |
| 13:27 | <jdike:#uml> | at that point, vcpu returns in the original context with info about what happened |
| 13:37 | <caker:#uml> | I see -- so it's a (new?) syscall on the host, and is more efficient than the current method used by skas at intercepting syscalls and signals |
| 13:39 | <jdike:#uml> | yup |
| 13:39 | <jdike:#uml> | one process, so no scheduling involved |
| 13:39 | * | caker:#uml wonders where he's been to have missed the vcpu discussions |
| 13:39 | <jdike:#uml> | one system call and you know what needs doing |
| 13:39 | <caker:#uml> | awesome |
| 13:42 | <jdike:#uml> | now all I need is for it to stop crashing the host |
| 13:44 | * | jdike:#uml doesn't ask for much |
| 13:50 | -!- | kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps] |
| 13:50 | <jdike:#uml> | har |
| 13:51 | <jdike:#uml> | slab debugging is telling me things |
| 13:55 | <jdike:#uml> | freeing something in the wrong place, but that shouldn't be harmful |
| 13:57 | <Supaplex:#uml> | like unintentionally freeing hardened criminals ;) |
| 13:58 | <jdike:#uml> | we wouldn't want criminal leaks |
| 14:02 | <Magotari:#uml> | I wonder if any security subsystems will be working after you are done with uml. :) |
| 14:02 | <Magotari:#uml> | Not like I care about any of that anyway... |
| 14:02 | <jdike:#uml> | people are so cynical |
| 14:36 | <Supaplex:#uml> | haha |
| 15:28 | -!- | mjf [~mjf@r9fk174.net.upc.cz] has joined #uml |
| 15:45 | -!- | ram [~ram@pool-72-90-103-104.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds] |
| 16:00 | -!- | kos_tom [~thomas@humanoidz.org] has joined #uml |
| 16:09 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has joined #uml |
| 17:15 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds] |
| 17:28 | -!- | dang [~dang@aa-redwall.ghs.com] has quit [Quit: Leaving.] |
| 18:14 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has joined #uml |
| 18:30 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving] |
| 18:32 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has quit [Quit: Leaving] |
| 18:37 | -!- | mjf [~mjf@r9fk174.net.upc.cz] has quit [Quit: leaving] |
| 18:47 | -!- | Urgleflogue [~plamen@83.228.65.158] has quit [Ping timeout: 480 seconds] |
| 19:41 | -!- | koid [~loid@d83-181-250-146.cust.tele2.it] has joined #uml |
| 19:46 | <koid:#uml> | hi everyone, which host process calls the function open_proc_mm()? |
| 20:18 | -!- | koid [~loid@d83-181-250-146.cust.tele2.it] has quit [Remote host closed the connection] |
| 21:24 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has joined #uml |
| --- | Log | closed Thu Mar 13 00:00:19 2008 |
