--- Day changed
--- Log opened Thu Feb 09 23:59:01 2006
00:13 -!- womble [~mpalmer@203.219.190.106] has quit [Ping timeout: 480 seconds]
01:26 < dave_> hmm, maybe not.
01:27 < dave_> I can get my switch to please a config eth0=daemon
01:27 < dave_> but anything beyond that just prink's some transmit failures :/
01:29 < dave_> uml_net_start_xmit: failed(-111)
01:39 -!- shehjar_ [~shehjar@60-240-80-162-nsw-pppoe.tpgi.com.au] has joined #uml
02:40 -!- Newsome [~sorenson@216-190-206-130.customer.csolutions.net] has quit [Quit: Linux: Now with employee pricing!]
02:41 -!- ams [1000@pv108234.reshsg.uci.edu] has joined #uml
02:56 -!- ram [~ram@pool-71-117-233-57.ptldor.fios.verizon.net] has joined #uml
02:57 -!- Shaun2 [Shaun@204.15.132.253] has quit [Ping timeout: 480 seconds]
03:10 -!- ams [1000@pv108234.reshsg.uci.edu] has left #uml [Leaving]
03:43 -!- ram [~ram@pool-71-117-233-57.ptldor.fios.verizon.net] has quit [Remote host closed the connection]
04:22 -!- Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #uml
05:56 -!- shehjar_ [~shehjar@60-240-80-162-nsw-pppoe.tpgi.com.au] has quit [Quit: shehjar_]
08:20 -!- da303king [~heiko@p4523e3d4.np.schlund.de] has joined #uml
08:47 -!- Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
08:57 < dgraves> dave_: perhaps uml_net with a tuntap would be easier?
08:59 < dave_> dgraves: the point there was that I'm writing my own switch daemon; so bypassing it isn't very interesting :-)
09:02 < dgraves> oh. yeah, i see that. i doubt there's a spec. if you talk to jdike later today, he wrote it, i think.
09:16 < dave_> it's okay for the time being. I figured out how to get a communication going between the VM and my switch.
09:17 < dgraves> oh, good!
09:17 < dave_> the code of the kernel driver is much clearer than the uml_router code; uml_router having to handle 4 different revs of the communication protocol makes it fairly obfuscate.
09:17 < dgraves> now you just need to make it take over the world.
09:17 < dave_> working on that too.
09:44 -!- Newsome [~sorenson@obelix.cs.byu.edu] has joined #uml
09:58 -!- silug [~steve@206.80.72.37] has quit [Ping timeout: 480 seconds]
10:04 -!- da303king [~heiko@p4523e3d4.np.schlund.de] has left #uml [? DIVISION BY ZERO]
10:50 -!- hfb [~hfb@pool-71-116-252-188.lsanca.dsl-w.verizon.net] has joined #uml
11:18 -!- ram [~ram@pool-71-117-233-57.ptldor.fios.verizon.net] has joined #uml
11:18 -!- hfb [~hfb@pool-71-116-252-188.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
11:42 -!- jdike [~jdike@pool-71-245-228-225.bstnma.fios.verizon.net] has joined #uml
11:42 < jdike> Hi guys
11:46 < dgraves> mourning jdike.
11:46 < jdike> Who are we mourning?
11:47 < jdike> your spelling abilities?
11:47 < dgraves> the trout i'm about to nuke you with.
11:47 * dgraves nukes jdike with a trout bomb.
11:47 < jdike> Uh oh
11:47 * dgraves nukes jdike with a trout mirv too.
11:47 * jdike investigates trout shelters
11:48 < dgraves> doggone it. don't make me nuke you more! will you just *stop moving*???!!!
11:48 < jdike> I'm gonna have a shelter
11:48 < jdike> I ain't gonna care what sorts of trouts you rain down upon me
11:49 * dgraves investigates sturgeon bombs then.
11:52 < jdike> man
11:52 < jdike> sturgeon shelters are *expensive*
11:53 < dgraves> yeah. so are the bombs.
11:53 < dgraves> don't make me.
11:56 -!- hfb [~hfb@pool-71-116-252-188.lsanca.dsl-w.verizon.net] has joined #uml
12:11 -!- ram [~ram@pool-71-117-233-57.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
12:37 -!- hfb [~hfb@pool-71-116-252-188.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
13:02 -!- the_hydra [~a_mulyadi@202.59.168.5] has joined #uml
13:02 < the_hydra> hi
13:04 < dgraves> hiya the_hydra
13:05 < the_hydra> hello allan
13:11 -!- Newsome [~sorenson@obelix.cs.byu.edu] has left #uml [Linux: Now with special employee pricing!]
13:13 < the_hydra> jdike: today I re-read about what you had said about userspace() in process.c
13:13 < the_hydra> jdike: for me, seems like this is similar to entry.S
13:13 -!- acklen [~kno@64.62.148.249] has quit [Read error: Operation timed out]
13:17 -!- tomimo [~kurre@a80-186-64-246.elisa-laajakaista.fi] has quit [Ping timeout: 480 seconds]
13:34 -!- acklen [~kno@64.62.148.249] has joined #uml
13:45 < jdike> yeah, pretty much
13:45 < jdike> very different in form, though
13:46 < the_hydra> jdike: yes, different form
14:06 -!- tomimo [~kurre@a80-186-64-246.elisa-laajakaista.fi] has joined #uml
14:06 < the_hydra> jdike: besides the different header files they use, is there any other difference between _user.c and _kern.c file?
14:06 < jdike> well, one is userspace code and the other is kernel code
14:07 < jdike> that's kind of a fundamental difference, even if it just amounts to the headers they use
14:12 < the_hydra> jdike: hm, for example, userspace() is put on process.c and the trap handler is on process_kern.c?
14:13 < jdike> right, userspace is full of ptrace and wait, so needs to be userspace
14:14 < jdike> the trap handler needs to call the IRQ system and page fault handler, so needs to be kernelspace
14:20 < the_hydra> those two codes (_user.c and _kern.c) are actually executed by two different threads?
14:22 < jdike> no
14:22 < jdike> there are direct calls between them
14:24 < the_hydra> hm i see
14:24 < jdike> it's just what headers they can use
14:25 < jdike> and they communicate (data passed across that boundary) using generic C types
14:25 < the_hydra> hm ok
14:34 -!- kos_tom [~thomas@humanoidz.org] has joined #uml
14:43 -!- the_hydra [~a_mulyadi@202.59.168.5] has quit [Quit: ]
14:46 -!- ams [1000@pv108234.reshsg.uci.edu] has joined #uml
15:09 -!- silug [~steve@206.80.72.37] has joined #uml
15:10 < dgraves> When Bob Kahn, Vint Cerf, and God were inventing TCP/IP, they didn't put much thought into how their technology might handle HDTV streams.
15:12 < jdike> No?
15:12 < jdike> shocking
15:13 < dgraves> ::L::
15:14 < jdike> Your porn is coming in a bit choppy?
15:15 < dgraves> i think you've got me confused with the_hydra, jdike. :)
15:15 < dgraves> its my martial arts flicks. :-P
15:15 < jdike> you're the one complaining
15:15 * dgraves checks.
15:15 < dgraves> wow! i *was* the one complaining!
15:15 < jdike> Ah, yes
15:15 < dgraves> dang. now how'd that happen?
15:15 < jdike> "martial arts"
15:16 -!- Newsome [~sorenson@216-190-206-130.customer.csolutions.net] has joined #uml
15:16 < dgraves> that's why i want more storage space!
15:16 < dgraves> actually, hdtv might just *kill* the porn industry...
15:17 < dgraves> have you ever thought about what those people might look like in HD?
15:17 * dgraves gags and wretches.
15:18 < jdike> hehe
15:18 < drrdarr> i have a question about disk writes in UML. Aren't write requests added to the linux elevator queue, and then serviced?
15:19 < drrdarr> A block write getting flushed to the disk (say /dev/hda6, a physical disk partition) traverses the following functions in the kernel: id
15:19 < drrdarr> e_do_request() -> start_request() -> do_request() -> do_rw_disk().
15:19 < dgraves> drrdarr: is this hd uml or sd uml?
15:19 * dgraves runs away.
15:19 < drrdarr> Does something change in the way block writes happen to virtual devic
15:19 < drrdarr> es in UML? The virtual devices should also be considered like a physical device right?
15:19 < jdike> yup, it's the same
15:19 < drrdarr> I am sorry, i do not understand the difference to sd and hd.. i am quite a newbie
15:20 < jdike> ignore him
15:20 < jdike> he's just a troublemaker
15:20 < drrdarr> :)
15:20 < jdike> except that UML uses the noop elevator
15:20 < drrdarr> o okay
15:20 * dgraves burns jdike's cookies then.
15:21 < drrdarr> i am working on an application that blocks disk writes and makes a copy of every block that is written to disk.
15:21 < drrdarr> i wrote it in the original kernel, but it hangs the system for some reason.
15:21 < drrdarr> when i implement the same thing in UML, I am not even able to see the disk block writes..
15:21 * dgraves is intrigued and waits for jdike's answer.
15:22 < drrdarr> I call my copy function from inside start_request() in drivers/ide/ide.c
15:22 < jdike> how does it hook into the block later?
15:22 < drrdarr> it taps all block writes in the original system..
15:22 < drrdarr> i get the data from the buffer head structure
15:22 < drrdarr> that is currently about to be removed from the elevator
15:23 < drrdarr> i just make a copy, and then leave the control back to the point in start_request() .
15:23 < drrdarr> and ddd for some reason always gives an error... errno = 3
15:24 < drrdarr> and it locks my slackware.img file, so i can't spawn the UML again!
15:24 < jdike> that's just because there are still processes from the UML still there
15:24 < drrdarr> okay
15:25 < jdike> what version of UML?
15:26 < drrdarr> i downloaded 2.4.20 source
15:26 < dgraves> ::blink::
15:26 < drrdarr> I am sorry, i should have mentioned that earlier!
15:26 < jdike> can you use a 2.6 kernel?
15:27 < jdike> much easier to debug
15:27 < drrdarr> i would like to stick to 2.4.. dunno much about 2.6 to start all over again..
15:27 < jdike> and much easier to get help with, since everyone has forgotten how 2.4 works
15:27 < drrdarr> o ok
15:27 < dgraves> jdike: what's 2.4?
15:27 < jdike> see?
15:27 < dgraves> i don't know this mythical 2.4 thing you speak of...
15:27 < drrdarr> :)
15:28 * dgraves isn't much help with 2.6 though... but at least people don't fall off their seat when they say 2.4...
15:29 -!- ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
15:29 < dgraves> oh good. i need more ram.
15:32 < drrdarr> jdike, i shall study the noop elevator and see if I am missing the control path (for a disk block write).. it would be great if i can see the values of the local variables in gdb.
15:32 < drrdarr> You said yesterday that it depends on gcc
15:32 < jdike> it has nothing to do with the elevator
15:33 < drrdarr> do i have to enable some flag before compilation?
15:33 < jdike> gcc can eliminate variables if it can prove they are the same as other variables it does preserve
15:33 < drrdarr> okay
15:33 < jdike> or if their values aren't needed yet or needed any more
15:33 < drrdarr> ok
15:35 < drrdarr> since i am new to UML, i thought that disk writes may be taking a different path in the code for virtual devices than physical devices.
15:35 < drrdarr> but since you said its not, i shall have to study the code again..
15:36 < jdike> exactly the same
15:36 < drrdarr> hmm
15:36 < jdike> things only change when they reach the disk driver
15:37 < drrdarr> okay.. i want to tap the write before the disk driver get the block (from the buffer cache, i think)
15:39 < drrdarr> also, another small question: is is true that the test (stub) program that calls the new system call i had written has to be compiled outside of UML, and then executed by mounting the host fs and accessing the executable there?
15:40 < jdike> no
15:40 < drrdarr> i tried writing the stub inside UML, but it could not find the system call entry point
15:40 < jdike> what was the exact error
15:41 < drrdarr> it used to complain that the system call was not implemented.
15:41 < drrdarr> you all helped me the other day with this stuff..
15:42 < drrdarr> i wrote the stub inside UML, made it include a file say somename.h which I put in /usr/include/sys
15:42 < jdike> what was the exact error
15:42 < drrdarr> just a moment
15:44 < drrdarr> perror result: Function not implemented
15:45 < jdike> that means UML didn't implement the system call
15:46 < drrdarr> I changed the /usr/include/asm/unistd.h to include the new system call.. this is the only place where i diverted from the instructions by Alexandros ..
15:47 < drrdarr> I had implemented all the other steps and built that kernel, and executed that..
15:47 < jdike> -ENOSYS means the system call wasn't implemented
15:47 < jdike> not present in the system call table
15:48 < drrdarr> but it seems to find the system call if i mount hostfs, and then execute the stub I had written and compiled outside UML
15:48 < drrdarr> okay
15:48 < jdike> in that case, the system call number was different inside UML than on the host or something
15:49 < drrdarr> okay, i shall check that once again.
15:49 < jdike> strace the two versions
15:49 < drrdarr> ok
15:49 < jdike> there should be some difference in that one system call
15:49 < drrdarr> ok
15:50 < drrdarr> will try it
15:53 < drrdarr> jdike, thx a lot.. going back to my block write implementation..