00:00:00 --- log: started osdev/03.06.21 00:03:40 --- quit: Kurt ("Connection reset by deer") 00:08:22 --- quit: dax (Read error: 110 (Connection timed out)) 00:30:19 --- join: kernel-panic (~panic@ANice-205-1-7-243.w81-53.abo.wanadoo.fr) joined #osdev 00:41:55 --- join: dax (dax@81.11.135.117) joined #osdev 00:44:31 --- join: witten (~witten@adsl-gte-la-216-86-199-140.mminternet.com) joined #osdev 00:47:46 --- join: trans (okkwir@fatwire-201-79.uniserve.ca) joined #osdev 00:58:18 ahhh 00:58:28 behh 00:58:36 finally finished converting library to mysql instead of flat file 00:59:02 now to write script that uploads links from file into database 01:08:46 seems noone interests this 01:38:38 --- join: wl (philipp@p508651A3.dip.t-dialin.net) joined #osdev 01:47:15 --- quit: dax (Read error: 110 (Connection timed out)) 01:56:29 --- quit: trans (Read error: 110 (Connection timed out)) 02:17:28 --- quit: Robert (Read error: 60 (Operation timed out)) 02:24:18 --- quit: cookin (Read error: 101 (Network is unreachable)) 02:25:17 --- quit: asmodeus (Read error: 110 (Connection timed out)) 02:25:17 --- quit: kdehl (Connection timed out) 02:27:20 --- quit: chille (Read error: 110 (Connection timed out)) 02:38:52 --- nick: geist -> geist-sleep 02:42:32 --- quit: lodda (Read error: 101 (Network is unreachable)) 03:08:50 --- join: trans (aqxutd@fatwire-201-79.uniserve.ca) joined #osdev 03:09:01 --- join: dax (dax@81.11.135.117) joined #osdev 03:09:29 --- join: gianluca (~glguida@ppp-86-133.28-151.libero.it) joined #osdev 03:09:56 hi 03:17:34 buh 03:18:43 ok 03:19:01 library is fully functional using mysql 03:19:13 now go break it 03:19:42 --- quit: air ("cria 0.2.8cvs15 -- http://cria.sf.net") 03:38:35 --- quit: redblue (Read error: 60 (Operation timed out)) 03:47:08 --- quit: trans (Read error: 60 (Operation timed out)) 04:01:21 --- quit: dax (Read error: 110 (Connection timed out)) 04:54:57 --- join: chille (chille@h155n1fls32o811.telia.com) joined #osdev 04:56:32 --- join: lodda (~playgroun@h138n2fls31o965.telia.com) joined #osdev 05:00:57 --- join: Robert (~snofs@h138n2fls31o965.telia.com) joined #osdev 05:03:21 --- join: asmodeus (~www@h125n2fls33o867.telia.com) joined #osdev 05:04:34 --- join: ADDOLT (~eirc@p508FF2F7.dip.t-dialin.net) joined #osdev 05:05:01 --- part: ADDOLT left #osdev 05:16:26 --- quit: lynx (Read error: 110 (Connection timed out)) 05:18:44 --- join: lynx (~lodsb@pD9E6317C.dip.t-dialin.net) joined #osdev 05:19:27 --- join: wl_ (philipp@p50864F9C.dip.t-dialin.net) joined #osdev 05:19:47 --- join: trans (expiah@fatwire-201-79.uniserve.ca) joined #osdev 05:19:51 --- join: kdehl (~kdehl@as3-2-3.sgp.lk.bonet.se) joined #osdev 05:19:59 --- join: dax (dax@81.11.135.117) joined #osdev 05:38:41 --- quit: wl (Read error: 110 (Connection timed out)) 05:55:40 --- quit: trans (Read error: 110 (Connection timed out)) 05:59:48 --- join: Ishq (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 06:02:30 --- quit: dax (Read error: 110 (Connection timed out)) 06:06:53 --- quit: Ishq (Connection reset by peer) 06:06:54 --- join: Ishq (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 06:07:16 --- quit: MoneyCat (Killed (NickServ (Ghost: Ishq!Ishq@frm-64-4-103-99.access.ntelos.net))) 06:07:18 --- nick: Ishq -> MoneyCat 06:10:01 --- quit: MoneyCat (Read error: 104 (Connection reset by peer)) 06:10:04 --- join: Ishq (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 06:10:05 --- nick: Ishq -> MoneyCat 06:15:48 --- quit: MoneyCat (Read error: 104 (Connection reset by peer)) 06:16:03 --- join: MoneyCat (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 06:31:21 --- join: jaf (~n4rfy@200.146.65.214) joined #osdev 06:31:28 supppppp 06:31:29 :~ 06:49:35 --- join: Matzon (Mazon@0x50a1b5bf.unknown.tele.dk) joined #osdev 06:50:48 luhsa 06:52:35 :* 06:54:11 sup jaf? 06:56:48 just coding new shit 06:56:49 you? 07:00:05 dont ignore me 07:00:07 I need love 07:00:08 :* 07:02:05 --- join: cookin (~jrydberg@h55n1c1o1044.bredband.skanova.com) joined #osdev 07:03:34 coders need no love! 07:03:40 coders need no emotions! 07:03:47 coders are productive 07:04:06 hehe 07:04:07 coders are gay then 07:04:08 LOL 07:04:19 gay == emotion 07:04:24 per old definition 07:04:35 some gays without emotion :) 07:05:23 jaf : coding some shite, too 07:06:42 nice :) 07:07:28 Im working on new sbox major register drivers to sbox 07:07:37 then I can using *bsd drivers 07:07:44 bsd license r0x 07:07:45 :) 07:07:55 you? 07:19:17 --- quit: gianluca ("using sirc version 2.211+KSIRC/1.2.1") 07:20:06 --- join: trans (vaxhgl@fatwire-201-79.uniserve.ca) joined #osdev 07:20:13 --- join: dax (dax@81.11.135.117) joined #osdev 07:20:45 hey dax 07:22:22 no, you are not working on your drivers 07:22:38 you are talking unnecessary stuff 07:29:38 --- join: Ghiottone (~ale@ppp-105-18.27-151.libero.it) joined #osdev 07:37:38 --- join: redblue (star@ppp037.216-96-207.sherb.mt.videotron.ca) joined #osdev 07:55:19 --- quit: Ghiottone ("Client exiting") 07:57:36 --- join: msa (~msa@APuteaux-115-1-18-213.w81-51.abo.wanadoo.fr) joined #osdev 08:15:19 --- quit: trans (Read error: 110 (Connection timed out)) 08:47:32 --- join: asmodeus_ (~www@www.sdrf.nu) joined #osdev 08:47:33 --- quit: jaf (Read error: 104 (Connection reset by peer)) 08:50:09 --- nick: Zenton -> Zenton_ 08:56:05 --- quit: dax (Read error: 60 (Operation timed out)) 09:01:22 --- quit: asmodeus_ ("leaving") 09:08:27 --- quit: redblue (Read error: 54 (Connection reset by peer)) 09:13:37 --- nick: Zenton_ -> Zenton 09:19:45 --- join: asmodeus_ (~www@stats.avesta.se) joined #osdev 09:19:58 --- nick: asmodeus_ -> asmo_wlan 09:30:59 --- nick: Zenton -> Zenton_ 09:42:48 --- join: redblue (star@ppp041.216-96-207.sherb.mt.videotron.ca) joined #osdev 09:44:21 --- join: trans (ehzaoq@fatwire-201-79.uniserve.ca) joined #osdev 10:08:22 --- join: newbs (newbs@ts1-illavl56.shawneelink.net) joined #osdev 10:16:22 --- join: dax (dax@81.11.135.117) joined #osdev 10:18:49 --- quit: asmo_wlan (Read error: 104 (Connection reset by peer)) 10:26:32 --- quit: trans (Read error: 110 (Connection timed out)) 10:34:36 --- join: revanthn (revanthn@202.9.183.170) joined #osdev 10:40:35 --- quit: Boney (Read error: 104 (Connection reset by peer)) 10:57:09 --- quit: file (Read error: 104 (Connection reset by peer)) 11:05:42 --- quit: wl_ (Read error: 60 (Operation timed out)) 11:19:10 --- join: z3r0_one (~z3r0_one@lsanca1-ar51-4-42-020-164.lsanca1.dsl-verizon.net) joined #osdev 11:22:22 --- join: jonn (~jonn@arnarson.is) joined #osdev 11:32:33 --- join: witten_ (~witten@adsl-gte-la-216-86-199-140.mminternet.com) joined #osdev 11:36:41 --- join: coredump (~ben@h00105a271fda.ne.client2.attbi.com) joined #osdev 11:43:17 --- quit: Mathis (Read error: 104 (Connection reset by peer)) 11:44:30 --- join: trans (rgmnup@fatwire-201-79.uniserve.ca) joined #osdev 11:49:15 --- quit: thib ("Client Exiting") 12:06:29 --- join: daxie (dax@81.11.135.117) joined #osdev 12:07:00 moo 12:07:06 quack quack 12:12:24 hi dax 12:22:22 --- quit: revanthn () 12:24:17 --- join: kernel2421 (~silvio@ppp-226-178.25-151.libero.it) joined #osdev 12:26:01 --- quit: dax (Read error: 110 (Connection timed out)) 12:52:22 --- nick: daxie -> dax 12:54:25 --- nick: geist-sleep -> geist 12:55:12 heya everyone, it's been super quiet 12:55:21 time to start all that osdev talk again 12:58:02 I made a little program to broadcast the contents of a term 12:58:10 so you can watch what people are coding 12:58:15 anyone wanna try it? 12:58:58 no download necessary 13:00:28 maybe in a minute 13:02:21 * dax yawns 13:06:46 witten_: yeah, shoot 13:06:52 I wanna see this program 13:07:32 ok 13:07:57 <--- tired 13:08:30 heh, cool 13:09:02 oh no, where'd your scheduler go! 13:09:30 geist: that's an old version 13:09:36 my most recent version is on my laptop 13:09:47 heh 13:09:51 anyway, this is pretty slock 13:09:54 er slick even 13:10:04 what does it do, connect to the pty and spew that out? 13:10:20 actually, it uses screen 13:10:29 you run screen -L 13:10:33 which logs the entire session to a file 13:10:34 oh, it looks at screen's pipe probably 13:10:42 ohhhhh, you're just tailing the file 13:10:44 and I hacked screen to do it every 100th of a second 13:10:46 well, it might be a pipe 13:10:54 yeah, I'm tailing the log file 13:10:59 and spewing it out via tcp 13:11:12 why does it only work one at a time? 13:11:38 dunno 13:11:45 probably I shouldn't be doing a while loop or something 13:11:58 I'm using twisted, which is a python framework for making servers 13:12:01 and I don't fully grok it yet 13:12:05 just started playing with it 13:12:09 ah 13:12:32 anyway, I think it'd be fun to have a bunch of windows open with different people coding 13:12:38 well, I logged off so someone else can try it out 13:12:43 ok 13:12:49 yeah unfortunately I use windows for all my coding needs 13:12:50 oh, that's another bug 13:12:55 hah, crashed? 13:13:02 --- quit: trans (Read error: 110 (Connection timed out)) 13:13:10 I had to kill the terminal, it didn't take ^D 13:13:11 doesn't crash.. it just doesn't work after the first person disconnects :) 13:13:25 though I should have popped into the terminal control screen 13:13:33 I don't know how windows telnet works but ^] followed by q and then enter should quit 13:13:37 that's a unix telnet thing 13:13:51 yeah 13:13:57 i didn't think about it at the time 13:14:06 I'm on my macosx box right now, so it was unix telnet 13:14:20 ah ok 13:18:15 anyone else wanna try? 13:18:34 --- join: eKIK (~ekik@h62n2fls31o858.telia.com) joined #osdev 13:19:15 witten: if i weren't this tired i would 13:19:34 heh 13:19:42 are you awake enough to fire up telnet? 13:19:52 no i couldn't do that atm 13:20:00 haha 13:20:03 get some sleep dood 13:20:07 didn't sleep to much last nite 13:20:22 take a nap 13:20:38 like 40 mins or so and i'm off for a good night's rest 13:20:40 i think 13:20:53 hah i was wasted like hell yesterday 13:21:01 fun fun ;) 13:21:06 and i didn't sleep cause i was thirsty like hell 13:21:12 :/ 13:21:23 I had a bunch of bad wine last night, but not enough to get wasted or sick 13:21:34 wine in a box? 13:21:40 heh, no 13:21:51 i had half a bottle of whiskey, in about 30 minutes, and i hadn't eaten anything yet 13:22:02 actually reasonably expensive stuff, but I think some of it had gone bad or was an acquired taste or something 13:22:08 dax: bad idea :) 13:22:13 geist: eww 13:22:15 well it was kind of fun 13:22:22 laughing at leaves cause they were green 13:22:24 things like that 13:22:33 woot 13:22:39 then let me guess, you smoked a bunch of dope? 13:22:41 good to know that when i'm drunk i just go happy and laugh even more than usual 13:22:48 ( 22:21:03 ) ( dax ) i had half a bottle of whiskey, in about 30 minutes, and i hadn't eaten anything yet 13:23:22 i don't smoke things 13:23:25 cause of my asthma 13:23:32 oh I thought you did. must be someone else here 13:24:40 anyhow... now i know that half a bottle of whiskey is enough to get pretty decently wasted 13:25:10 and i also learned that i ought to get an other brand if i ever do that again 13:27:04 * geist is gonna hack code today 13:27:21 gotta further my newos ppc efforts. I'm not getting stuff done as fast as i'd like 13:27:49 I know the feeling 13:27:51 hope i can sleep properly tonight so i can code a bit tomorrow 13:38:13 --- join: _eKIK (~ekik@h62n2fls31o858.telia.com) joined #osdev 13:44:54 --- join: Ishq (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 13:45:15 --- quit: MoneyCat (Killed (NickServ (Ghost: Ishq!Ishq@frm-64-4-103-99.access.ntelos.net))) 13:45:19 --- nick: Ishq -> MoneyCat 13:45:26 --- quit: witten_ ("Client exiting") 13:48:48 --- quit: MoneyCat (Read error: 104 (Connection reset by peer)) 13:50:03 hmm 13:50:48 --- join: MoneyCat (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 13:51:41 --- quit: dax (Read error: 110 (Connection timed out)) 13:54:25 --- join: Dr_Evil (DSLflat@p508FF688.dip.t-dialin.net) joined #osdev 13:54:40 --- quit: eKIK (Read error: 110 (Connection timed out)) 14:08:04 --- nick: z3r0_one -> Homer 14:08:20 --- nick: Homer -> Homer_J_Simpson 14:08:22 --- join: jsr (www@du-14-237.ppp.telenordia.se) joined #osdev 14:15:46 --- join: nairou (~nairou@adsl-63-201-210-123.dsl.lsan03.pacbell.net) joined #osdev 14:16:06 --- join: mrMister (~andri@ti122110a080-0648.bb.online.no) joined #osdev 14:16:49 oh sweet, ppc has 8 generic registers that can only be read by supervisor space 14:16:56 that has a lot of possibilities... 14:17:10 wow yeah 14:17:47 oh wait, only looks like 4 14:17:55 8 on a POWER or something 14:19:05 supervisor space = equivalent to ring 0 on x86? 14:19:09 I can use 2 of them in exception processing, and my guess is use the 3rd to store the current thread pointer, and the 4th to store the current kernel stack 14:19:21 yeah supervisor == ring 0 14:19:41 cool 14:19:54 very nice 14:20:04 I had to use drX on x86 for the same purporse 14:20:08 man, all these cool features that x86 is missing out on 14:20:16 err, really? 14:20:16 and only if I forget using any sort of debugging stuff 14:20:22 yeah 14:20:40 yeah, I store the current thread pointer in dr3 I believe 14:20:53 actually, no it stores the pointer to the current cpu structure, which has a pointer to the thread it's running 14:22:39 --- nick: Homer_J_Simpson -> z3r0_one 14:24:19 this is super irritating though: the ppc turns off the mmu when it takes an exception 14:24:24 --- join: silvio_ (~silvio@ppp-111-184.25-151.libero.it) joined #osdev 14:26:36 oh I know what i can do 14:27:08 I'll put these exception handlers in a segment that I relocate to where it has to be (0xfff00000) or something 14:27:21 then I dont have to dick around with the pc to get it into kernel space when I turn the mmu back on 14:30:29 --- quit: redblue (Read error: 54 (Connection reset by peer)) 14:31:10 geist: and to think, we do this sort of thing for fun 14:31:35 heh yeah 14:37:03 --- join: redblue (star@ppp105.216-96-207.sherb.mt.videotron.ca) joined #osdev 14:37:21 --- join: trans (tkjlrz@fatwire-201-79.uniserve.ca) joined #osdev 14:37:56 okay, screw the seperate section thing 14:38:19 I'll just put a var in front and behind the vectors, and copy them there when the kernel comes up 14:38:32 and make sure the vector code is position independant 14:39:43 geist what version of gcc you use? 14:39:48 3.0.4 14:40:09 any trouble transitioning from 2.95? or did you always use 3.0? 14:40:23 not really 14:40:45 I transitioned into it when doing the SH port. 2.95.x produced broken SH code a lot 14:40:53 huh 14:40:54 so most of the dev of newos has been 3.0 14:41:25 and 3.0 was the most current release at the time. I haven't moved off it onto anything newer yet 14:41:27 * witten rewrites context switching for the third time 14:41:59 geist: you use gcc on windows? 14:41:59 I suppose I should switch at some point 14:42:05 witten: yes 14:42:10 cool 14:42:56 2.95 works fine for me, but I'm sure I'll have to update down the road, especially when get to porting gcc for self-hosted compiles 14:44:21 * geist shrugs 14:44:32 heh 14:44:34 it works okay, there are no gotchas that I'm aware of where you really need it 14:44:47 I do use c99 stuff more and more though, so you need gcc 3 for that 14:44:57 ah 14:44:57 I'm starting to get lazy and declare variables as I need em 14:45:06 and inline functions 14:45:08 --- join: malenfant (~malenfant@bmjc1gvy308a.bc.hsia.telus.net) joined #osdev 14:45:18 --- quit: malenfant (Remote closed the connection) 14:46:20 --- quit: kernel2421 (Read error: 110 (Connection timed out)) 14:46:41 I declare variables as I need 'em 14:46:45 but then again, I'm using C++ 14:47:51 --- quit: jsr (Read error: 110 (Connection timed out)) 14:48:17 ah nuts, and here I thought I was the only one dumb (crazy) enough to do that =P 14:48:17 good night 14:48:20 --- part: silvio_ left #osdev 14:48:55 night is young, be still 14:49:13 heh 14:49:17 I've seen it done 14:49:22 works okay, not my thing 14:51:01 --- join: yuriz (~yuriz@rcr.teraflops.com) joined #osdev 14:54:55 --- part: yuriz left #osdev 14:55:03 --- join: TB- (ThunderOS@212.59.18.97) joined #osdev 14:55:22 hi 14:55:37 does anybody here use vmware? 14:56:07 not in a while 14:56:15 but I have 14:56:24 I have in the last 14:56:27 past 14:57:41 how did you guys were testing your OS's, like did you write it to floppy or link vmware with hdd? 14:57:46 how can I save the registers of a task from my timer handler? if the stub is in asm and I pusha there, then when I call the main C handler function, the stack pointer is somewhere else. should I pusha from the C handler instead? 14:58:01 TB-: I use bochs myself 14:58:11 I wrote it to a floppy and had vmware boot off it 14:58:13 TB-: run it on a floppy image I generate with a script 14:58:47 I used GRUB to boot, so the kernel was just an ELF file on a DOS disk 14:59:08 witten: have we not gone through this before? 14:59:19 geist: I think we have :) 14:59:29 write a function called context_switch() that pushes the regs on the stack, switches to a new stack, pops the regs from it 15:00:00 TB-: I test on a real computer via floppy 15:00:08 or in the case of mac/dreamcast over the network 15:00:12 geist: I did 15:00:18 thats what I do now 15:00:39 geist: but for various reasons, I have to actually save all the registers into the task struct 15:00:53 witten: okay, so what's the problem? 15:01:07 change the function to pass the old and new thread structure pointer 15:01:30 save the regs in the old thread structure (including the stack), load the new ones, load the stack, ret 15:01:40 geist: I'm a bit unclear on what the asm stub timer handler should do and what the C portion it calls should do, and then what context_switch() (which can be called from anywhere, not just the timer handler) should do 15:01:49 I'll play around with this some more 15:01:51 k 15:02:24 hrm, not enough sprg regs (only 4) to write my exception handler the way i want to 15:02:45 guess you need to use powerpc :) 15:02:57 hmm? 15:03:33 didn't you say thta had 8 regs? 15:03:51 yeah, thought so, but it is only one of the powerpcs (4xx) 15:04:02 witten: I have the asm stubs do all the register saving/restoring, that way the C portion can be a regular function and not worry about that stuff 15:04:08 not the G3/G4, which are the only ones I'm remotely interested in 15:04:18 ie 750/7450 15:04:46 nairou: how do the asm stubs know where to save/restore them? 15:04:56 nairou: the addresses of the C task structs that hold the registers.. 15:05:02 geist: oh ok 15:05:08 geist: guess you're screwed then :) 15:05:09 witten: they automatically get put on the kernel stack, declared in the current TSS 15:05:32 nairou: so you don't save registers anywhere other than the stack? 15:05:48 witten: no, I don't. simpler that way 15:05:59 I was doing that too originally 15:06:30 but I have to forge stack pointers and such so iret works properly even on threads that have never been interrupted by the timer handler 15:07:40 witten: nah, there are some other regs I can use for this purpose 15:07:53 witten: when your C function ends, it returns to the asm stub right? 15:08:10 --- join: Boney (~boney@user-0can1b0.cable.mindspring.com) joined #osdev 15:08:13 geist: oh ok, cool 15:08:16 witten: the stub can then undo all the register saving it did, and return from the interrupt 15:08:18 nairou: it does now, yeah 15:08:53 nairou: hm 15:09:51 --- join: pavlovski (~tim@host217-44-188-189.range217-44.btcentralplus.com) joined #osdev 15:10:09 hi all 15:10:12 witten: though I push/pop all the registers manually, had more luck that way 15:10:17 hey pavlovski 15:10:27 hmm 15:11:21 --- join: Apocalypse (yexmh@195-23-155-160.nr.ip.pt) joined #osdev 15:11:38 ko 15:12:51 [Hirogen2] can anyone tell me where can i find good tutorials about OS development?? 15:12:57 about multitask to be more acurate 15:13:25 Apocalypse: try the links in the topic 15:13:42 ok 15:18:46 that's so lame. if you start vim in read only mode it doesn't load a lot of the syntax coloring and other fun stuff 15:18:50 seems to disable that 15:19:14 that'd odd 15:19:46 mine doesn't do that 15:19:47 yeah, if you start vim with -R (which is what 'view' does) 15:19:57 :syntax on and whatnot are totally unsupported 15:20:11 --- quit: TB- () 15:21:33 not here 15:21:50 huh, dunno 15:22:13 what version of vim? 15:22:24 6.1 15:22:27 on freebsd 15:22:55 6.1.320 here 15:22:57 on debian 15:23:22 --- join: file (~intranet@mctn1-2374.nb.aliant.net) joined #osdev 15:23:32 --- join: thib (~thib@bofh.bitcode.org) joined #osdev 15:23:48 argh... sooo... hungry... 15:24:06 * file finishes fixing his fileserver 15:24:19 yup... works 15:24:20 * file cheers 15:24:22 pavlovski: Then order pizza 15:24:33 huh... installed gcc3.3 (freebsd package), but I see no sign of it... weird... 15:24:56 gcc33? 15:25:05 gcc-3.3_20030514 15:25:19 3.3.2? 15:25:19 oh wow 15:25:23 * file frowns 15:25:30 yup thats it, jeez 15:25:31 I've been working too long, forgot the last bit was a date 15:25:42 --- join: Mathis (irc@pD9EA9AC7.dip.t-dialin.net) joined #osdev 15:26:20 cool 15:26:52 hi 15:26:58 thib: I'm making some food 15:27:05 although it is 2330 15:27:26 [00:27:05] although it is 2330 15:27:35 pavlovski: you are about an hour ahead of me ( it´s 2230 here in .is ;) 15:27:41 Mathis: there be timezones ;) 15:27:54 his clock is 3 mins in the future... 15:28:04 --- join: dax (dax@u212-239-163-16.adsl.pi.be) joined #osdev 15:28:39 my girlfriend just named my laptop 15:28:44 wtf 15:28:50 witten: interesting 15:29:58 [23:27] although it is 2330 15:30:30 lol 15:34:39 * pavlovski contemplates how to design automatic dialog control layout 15:35:17 pavlovski: interesting 15:36:06 --- quit: Matzon () 15:36:27 anyone have a link for syntax changes in gcc 3.x? its complaining about my inline asm code 15:36:54 gcc.gnu.org possibly 15:37:08 yeah I'm there now 15:41:24 argh, why isn't this local label working? 15:41:34 alguem aki fala poruguês?? 15:42:16 nadie 15:42:30 geist: what's the problem? 15:42:48 ninguem 15:43:20 well, I'm trying to use a local label (ie, 1:) and it's complaining about multiple ones 15:43:31 shit I see why 15:44:09 oh yay, now I'm triggering an internal assertion in binutils 15:44:59 hm 15:45:12 it's OK, it's open source, so you can fix the bug yourself and be on your way ;) 15:45:22 that's right 15:45:25 damn found the problem 15:45:30 "gcc 3.3 no longer allows multi-line string literals" 15:45:43 heh, dont do that 15:45:57 it was for multi-line inline asm 15:46:01 [witten] falas portugês? 15:46:06 oh well, easy to fix 15:46:45 well shit 15:46:50 so I'm doing a local label 15:46:56 ie, bne 1f 15:46:59 couple of lines later 15:47:00 1: 15:47:07 but it's in a macro, which is expanded like 15 times 15:47:19 so in the second or third expansion, gas panics 15:47:27 hey, anybody here can compile bochs under linux without errors??? 15:49:24 ah I see what's up 15:50:53 here's what you can't do 15:50:57 label: 15:51:02 . = label + constant 15:51:06 func: 15:51:13 . = label + bigger constant 15:51:16 func2: 15:51:21 . = label + bigger constant 15:51:28 and then use a local label, that makes gas crash 15:51:39 but you can do 15:51:42 label: 15:51:50 .skip constant - (. - label) 15:51:52 func: 15:51:59 .skip bigger constant - (. - label) 15:52:03 func: 15:52:04 etc 15:55:06 Apocalypse: no 15:55:56 [witten] if you don't know how did you understand the question?? 15:56:06 no portugues aki 15:56:13 Apocalypse: I took spanish 15:56:34 in school 15:56:48 ah! ok 15:58:08 Seinfeld time 15:59:54 huh 16:00:09 now it compiles fine with gcc33, but wont boot 16:00:16 wonder what else changed 16:07:28 bitrode 16:08:23 bitrot 16:08:38 ? 16:09:46 geist: Or that ;) 16:09:56 No coffein me not spellink so good 16:10:07 nairou: compile with varying optimization levels, see if it goes away 16:10:21 ah ok 16:10:32 --- quit: z3r0_one ("Now committing seppuku daily for the last time...") 16:11:48 --- quit: Mathis ("good night") 16:11:53 --- quit: mrMister ("leaving") 16:12:07 aha 16:12:20 turned off optimizations (-O2), not it runs 16:12:21 crap 16:12:27 not = now 16:13:03 so is gcc33 being fussy, or am I doing something archaic? 16:13:55 oh it's for sure your fault 16:14:03 hehe 16:14:08 weird though 16:14:12 a new optimization is causing some assumption you made to be fause 16:14:14 false 16:14:27 huh 16:14:28 lots of times a var needs to be volatile and you got away with it, for example 16:15:49 --- quit: _eKIK () 16:17:10 ok so gcc33 is just being more strict 16:18:15 or mmore loose actually 16:18:21 heyas 16:18:28 it has additional optimizations that broke what you were doing, for sure 16:18:41 hiya kyelewis 16:18:47 * geist has the ppc exception stuff nearly done 16:18:51 or the prelim stuff 16:19:07 i'll take it that's a good thing? :P 16:19:34 i might have the opportunity to pick up an old ppc for free soon - would that be a good thing? 16:19:53 what ppc? 16:19:56 hold old? 16:20:29 not sure exactly - the school was using them up until the end of 1999 16:20:56 and then they put them in storage, and they want to chuck them away this year 16:21:40 is it a mac? 16:21:52 i actually don't know - but i assume so 16:22:07 i assume they're the macs that schools all used to have 16:24:05 the key word, however, being *free* - the only cost is in my time getting it from point A to point B 16:24:18 i just wanted to know if it could be any use for anything 16:24:43 well worst case you can throw it into the middle of a busy intersection 16:24:59 lol 16:25:17 so I always have to think about this 16:25:26 i know they're in a working state anyway 16:25:37 pushing onto a stack predecrements it, right? 16:25:39 I think so 16:26:03 yeah it would have to, on x86 anyway 16:26:34 so on ppc a push is 16:26:48 stwu rS,-4(stack reg) 16:26:49 what does the processor push onto the stack when an interrupt happens? eflags, cs, eip? 16:26:55 on x86? 16:26:55 on what cpu? 16:27:00 on x86 yeah, it does 16:27:07 ok 16:27:11 er, depends which mode 16:27:16 and where the interrupt is going 16:27:28 the x86 has four types of pmode interrupt stack frames alone 16:27:55 ok, well pmode timer interrupt 16:28:21 what's the current ring, and which ring is handling it? 16:28:35 actually, I'm not going to give you a full answer here (can't) 16:28:41 pavlovski: 0, 0 16:28:42 better to look in the Intel manuals for diagrams 16:28:49 ok 16:30:26 --- quit: kernel-panic ("bbl") 16:30:40 geist: if sometimes a task is going to be switched via manually yielding, and sometimes it's going to be switched by the timer interrupt, then how do you reconcile the need for what's on the stack to be different in each case? 16:30:55 --- join: Matzon (Mazon@0x50a1b5bf.unknown.tele.dk) joined #osdev 16:31:23 if it's yielding, all you've got on the stack is the eip to ret to. if it's being switched by the timer interrupt, then you've got eflags, cs, and eip 16:31:51 and trying to iret to a task that was previously yield()ed is simply not going to work 16:32:06 nope, it's not that complicate 16:32:09 complicated 16:32:19 well then I guess I'm making this overly complicated :) 16:32:22 so in the case of yielding, you have to disable interrupts across the context switch, right? 16:32:29 right 16:32:38 --- nick: kyelewis -> kye_brkfast 16:32:59 so if you take an interrupt, and then context switch to a thread that had yielded, the new thread should enable interrupts again 16:33:26 ok.. 16:33:31 ie, it's not really important that a interrupt is matched with an iret right then 16:33:44 that's not what I'm asking.. lemme rephrase 16:34:01 it's the contents of the stack that I'm worried about 16:34:07 I think it is, you just haven't realized it yet 16:34:12 ok.. 16:34:19 k, ask awya 16:34:58 if you take an interrupt, and then context switch to a thread that had yielded previously, then all that's going to be on the stack for that thread is the eip to return to. but what needs to be on the stack is eflags, cs, AND eip to iret to 16:35:15 nuh uh 16:35:20 nuh uh? 16:35:24 nope, dont need that 16:35:25 where am I going wrong? 16:35:39 you're not thinking in the right way 16:35:44 ok 16:35:50 you're thinking that since you took the interrupt you have to return from it *right then* 16:35:53 but you dont 16:36:08 what else can I do? 16:36:17 it's a non-problem 16:36:39 you're switching to *a new thread* which was doing *something completely different* so let it go finish what it was doing 16:36:49 if the new thread wasn't taking an interrupt, then so be it 16:37:05 hrm 16:37:06 which means you dont technically return from the interrupt you took initially until you switch back to the first thread 16:37:43 interesting 16:37:48 each thread is totally indepedant of each other in terms of their execution path down to the last instruction 16:37:59 so how do you know when to iret? 16:38:17 when you switch back to the thread that had context switched when taking the interrupt 16:38:28 it'll finish what it was doing, which involves calling iret 16:38:48 is it starting to make sense? 16:39:01 and how do you prevent a triple fault.. won't the processor get its panties all in a bundle because none of these interrupts are being returned? 16:39:03 somewhat, yeah 16:39:04 it's kind of a brain twister, but when you finally grok it it all makes sense 16:39:13 it's a lot easier than what I was trying to do 16:39:19 no no, the cpu doesn't care if an interrupt isn't returned by an iret 16:39:26 really 16:39:30 as long as the pic is cleared? 16:39:34 all an iret does is pop some shit off the stack 16:39:39 the cpu doesn't care about the pic 16:39:48 you had better clear it before you context switch though 16:39:49 ok 16:40:10 well thanks for clearing this up 16:40:10 in case of context switching during an interrupt call, you need to do it as the very last thing 16:40:29 right before iretting, because if you have any other housecleaning to do (like acking the pic) it might not happen for a while 16:40:50 so a context switch involves a jmp in this case? 16:40:59 ??? 16:41:08 no it involves a call to context_switch() 16:41:09 I mean, the last step of the context switch 16:41:13 right 16:41:23 save stack, go to next task, load stack, jmp? 16:41:29 no, ret 16:41:42 since you switched to a new stack, it has the proper return address on it 16:41:48 I see I see 16:42:00 is it getting a little clearer? 16:42:07 yes, thanks profusely 16:42:12 this'll save me much headache 16:42:15 the other thing I'd suggest you do is generalize the context_switch logic on the interrupt handlers 16:42:27 what I do and most big oses do is have the interrupt handler glue call the handler function 16:42:34 which does whatever it needs to service the interrupt 16:42:56 and if the handler function returns TRUE or some other flag, the interrupt handler glue calls context_switch as it's last thing 16:43:10 hm 16:43:11 so that way any interrupt can set up a context switch if it wants to 16:43:17 cool 16:43:33 and for the case of the timer interrupt (if you want to just have it preempt things), the handler can basically just return TRUE 16:44:04 make sense? later on you'll want other device interrupts to set up context switches to, and this becomes a lot more useful 16:44:30 for example, the keyboard interrupt handler probably wants to set up a reschedule if it had woken up a thread waiting on the keyboard queue 16:44:39 makes sense 16:44:44 otherwise you'd have to wait until the preemption timer came along 16:44:50 although I think for now I'll just get it working with the timer handler and then generalize 16:44:59 when I initially wrote my netstack the ping time was terrible 16:45:17 and I finally traced it to me forgetting to set up a reschedule after getting a packet in the nic driver 16:45:40 can't you call yield() or context_switch() there instead? 16:45:47 no you cant 16:46:00 you have to return the TRUE, and let the interrupt glue do it 16:46:06 ok 16:46:19 because what ifyou have chained interrupt handlers? you dont want the first one doing it and starving out the secoind handler 16:46:21 --- quit: Apocalypse ("Fácil de usar e super completo »¡« Scøøp Script 2002 »!« pegue o seu em www.scoop.com.br") 16:46:28 true 16:46:38 and secondly, the irq glue can do the PIC acking 16:46:53 that way every device driver doesn't have to ack the PIC itself, it shouldn't care about that stuff 16:47:18 starting to make sense? 16:47:19 right 16:47:38 yup 16:47:44 anybody get the latest Compgeeks new arrivals e-mail? 16:48:03 I knew that my approach felt a bit.. odd.. 16:48:43 yeah, it should be pretty straightforward, if you know how to do it. ) 16:48:55 --- nick: kye_brkfast -> kyelewis 16:49:23 geist: heh 16:52:18 --- quit: pavlovski (Read error: 54 (Connection reset by peer)) 16:55:10 --- quit: kyelewis ("kyelewis has no reason") 16:57:20 okay, got the frame pushed, time to pop it off 16:58:31 geist: with just 4 reg? 16:58:54 no no 16:59:05 I just had 4 regs to play with before I figured out what kernel stack to use 16:59:12 then I pushed all of the regs onto it 16:59:29 the ppc, like most other risc machines, doesn't do *anything* for you when it takes an exception 16:59:39 you have to load the new stack, push stuff onto it, etc 16:59:49 of course that means it's really flexible how you do it 16:59:54 yah 16:59:58 doesn't tie you down 17:00:47 --- quit: coredump ("I like core dumps") 17:01:07 oh now I see why beos put it's kernel at 0 instead of 0x80000000 17:01:15 it's much more convienient for ppc 17:01:25 shit, this is gonna be messed up 17:02:17 so the exception vectors on ppc *have* to be at 0x00000000 or 0xfff00000 in physical memory 17:02:29 those are the only two options, and when you take an exception the mmu is automatically turned off 17:03:36 so the problem is how do you turn it back on and get back into the kernel's mapping space 17:03:55 yeah, very nice. same reason why I couldn't properly trap 0 pointer accesses at work with vxWorks on ppc 17:04:08 yup 17:04:18 protecting the first page would have trapped all the interrupts, too 17:04:27 yup 17:04:36 if you're mmued it's less of a big deal 17:05:05 but that means you can't have 0 identity mapped, so I guess I'll have to do a trick where I turn on the mmu and add a constant to my program counter all at the same time or something 17:05:10 yeas, we could have done something, this was way to much trouble, because the vxWorks memory management was already in use 17:05:13 so that I jump back into the same code as it's mapped in the kernel 17:05:37 why does it *have* to be at 0x00000000 or 0xfff00000? 17:05:46 that's the way it was designed 17:06:07 if it was that in virtual space it'd be a lot easier 17:06:13 in fact, the standard arm9 does that 17:06:32 you can have it at 0 and 0xfff00000, but on top of paging, so it's really just a matter of putting a couple of pages there 17:07:26 nice 17:07:37 slice 17:09:52 anyway, I need to get some food 17:09:57 then I'll figure it out 17:12:04 yes, it must be possible, just vxWorks mmu support functions were broken and didn't work 17:12:28 going to watch twin peaks now :) 17:17:05 --- quit: Boney (Read error: 104 (Connection reset by peer)) 17:22:43 --- join: Boney (~boney@user-0can1b0.cable.mindspring.com) joined #osdev 17:23:14 --- quit: redblue (Connection reset by peer) 17:24:48 --- quit: jonn (Remote closed the connection) 18:00:46 woohoo 18:00:57 finally got my code to boot with gcc33 18:01:11 good, what did you have to change? 18:01:25 gcc33 was creating extra data segments that my ld script wasn't handling 18:01:30 ah ha 18:05:40 --- quit: thib ("leaving") 18:17:25 --- quit: Dr_Evil () 18:18:50 --- quit: trans (Read error: 110 (Connection timed out)) 18:19:07 argh 18:21:04 guess what 18:21:06 i'm drunk 18:21:32 haha 18:22:29 cookin: awesome! 18:22:34 lol 18:23:41 geist: you couldn't guess that, could you? :) 18:24:07 damn, there were some hot bitches out tonight. 18:24:18 but i only got to make out with one of them 18:25:04 (well, she's my friends little sister) 18:25:17 i know, i'm bad. 18:26:33 *shrug* 18:26:38 and my throat hurts. 18:27:11 hell, she more or less forces me to do it. :) 18:27:16 forced 18:27:50 what the heck, maybe i should see the ring now. 18:27:56 anybody seen it? is it any good? 18:28:34 nevermind. bbl. see you fellas. 18:28:36 later 18:32:51 hmm, i wonder if I can turn the mmu on by setting the IR and DR bit in the msr and use the next instruction to branch to a new spot 18:37:13 well I'm off for a while, see you all later 18:37:40 --- part: nairou left #osdev 19:18:14 --- quit: dax (Read error: 110 (Connection timed out)) 19:24:53 --- join: trans (bmhrov@fatwire-201-79.uniserve.ca) joined #osdev 19:33:31 --- quit: msa (Read error: 110 (Connection timed out)) 19:43:25 --- join: phsilva (~phsilva@200.173.189.144) joined #osdev 19:52:29 --- quit: Boney ("Lost terminal") 19:55:11 --- quit: phsilva ("Client exiting") 20:00:39 --- join: Mathis (irc@pD9EABF7A.dip.t-dialin.net) joined #osdev 20:00:49 hi 20:07:15 hody Mathis 20:08:16 did you change 'howdy' to 'hody'? 20:10:02 no I mistyped it 20:11:16 I learned alot about 'god' 20:13:27 instead of believing into him/her, humans should believe in themselve 20:15:43 geist: do you know Moses? 20:16:47 hmm? 20:17:12 Multi Operating System Environment System (or so...) 20:17:17 nope 20:17:38 GalaxyClustering would be something like that 20:18:47 where a System Manager manages the cooperation between multiple OSes on one machine 20:18:54 oh 20:19:50 we talked about VMSclustering 20:20:00 you told me that your school had one 20:20:40 yup 20:21:22 but your school does not have a machine which can run more than one OS at a time, right? 20:22:01 they had some mainframes 20:22:11 those are set up to run multiple oses 20:22:57 for what purposes does a school need mainframes? 20:23:05 * geist shrugs 20:23:13 I think they still ran a lot of their database stuff from it 20:23:28 do remember this was like 5 years ago 20:24:42 would be interesting to see this System Manager... 20:25:18 they've probably since moved their stuff over to more modern stuff 20:25:34 but they kept em around. I know they finally shut down the Cray MP-1 while I was there 20:25:46 and I think they were phasing out the VMS cluster 20:26:01 i think you couldn't log into it in 2000 or so, they probably shut em down 20:26:44 I have some kind of idea, how this System Manager works 20:26:56 it is like VMware 20:27:40 the only difference is, that the OSes run by the System Manager cooperate with it 20:27:58 where OSes run in VMware do not even know it 20:29:55 oh bummer, my old school has 802.11 now 20:30:02 that would have been really cool to have 20:30:56 Firewire? 20:31:01 or was it WLAN? 20:31:02 huh? 20:31:09 802.11 == wireless lan 20:31:24 WLAN... 20:31:35 802.11 20:31:48 I always refer to it as that, because it's totally explicit what it means 20:31:53 no room for confusion 20:34:25 we all could do the same 20:35:07 instead of writing words we should just refer to them in our dictionaries 20:38:50 --- join: dax (dax@u212-239-163-16.adsl.pi.be) joined #osdev 20:55:56 gtg, sleep required 20:55:58 --- quit: Mathis ("good night") 21:02:29 yawn 21:04:28 --- quit: trans (Read error: 60 (Operation timed out)) 21:05:30 crap, so I still dont have a good general solution to the 'how do I switch back into the kernel from an un-mmu translated exception handler' 21:05:53 looks like linux has a terribly complicated solution to the same problem, and netbsd has a really inefficient solution 21:05:56 I know I can do better 21:14:16 --- quit: dax (Read error: 110 (Connection timed out)) 21:31:47 --- quit: witten ("Client exiting") 21:44:00 --- join: redblue (star@ppp060.216-96-207.sherb.mt.videotron.ca) joined #osdev 22:09:05 --- quit: chille (Read error: 110 (Connection timed out)) 22:09:37 * geist is gonna try a trick that I dont know will work 22:09:59 turn on the mmu and in the next instruction jump to the address that's translated 22:10:03 dunno if that'll work 22:38:54 --- join: trans (kkoriq@fatwire-201-79.uniserve.ca) joined #osdev 22:39:08 --- join: dax (dax@u212-239-163-16.adsl.pi.be) joined #osdev 22:39:37 --- quit: newbs ("out like a spandex jumpsuit") 22:40:07 --- nick: geist -> geist2 22:40:22 --- join: geist (~geist@dsl093-182-050.sfo2.dsl.speakeasy.net) joined #osdev 23:05:36 --- quit: trans (Read error: 60 (Operation timed out)) 23:14:33 slow today 23:31:15 check this out, this is whack. first instructions of the kernel (compiled from C) 23:31:22 stwu r1,-32(r1) 23:31:24 mflr r0 23:31:32 stw r29,20(r1) 23:31:39 stw r31,28(r1) 23:31:51 stw r0,36(r1) <<---- WTF! 23:32:22 the first store would have kicked r1 down by 32 bytes 23:32:45 but then the last one would have stored data *above* where the stack pointer was when it started 23:32:47 that aint right 23:34:24 hrm, the abi always seems to do that, strange 23:40:21 --- quit: dax (Read error: 60 (Operation timed out)) 23:42:10 --- join: newt (newt@12-208-222-49.client.attbi.com) joined #osdev 23:43:00 hi, I have this mp3 player that I would like to write a driver for in linux, but the vendor will not give me the specs. Am I out of luck or can I have any hope of reversing the windows driver ? 23:44:42 well, what kind of interface does it speak? usb? 23:44:48 usb 23:44:59 and I assume that no one else has figured it out thus far? 23:45:05 yup 23:45:24 I've got the w2k driver file ... about to disassemble it 23:45:30 --- join: witten (~witten@adsl-gte-la-216-86-199-140.mminternet.com) joined #osdev 23:45:33 and I assume you dont have a usb bus analyzer 23:45:38 nop 23:45:40 that makes it pretty easy to figure 23:45:43 bummer, I hav eone 23:45:59 how much are they ? I've got several devices I want to drivers for 23:46:05 very expensive 23:46:35 oh :/ 23:47:05 the good thing is that the windows2000 drivers isn't very large and I have some advanced tools to do a disassembly 23:48:05 does that seem even possible or am I just wasting my time ? 23:48:20 probably wasting your time 23:48:33 can you tell me why ? 23:48:34 unless you are really familiar with the win2k usb stack, and have some sort of ICE 23:48:47 no ICE 23:48:48 and you have the DDK 23:49:01 you wont be able to make heads or tails from the win2k driver calls 23:49:02 have the DDK 23:49:23 --- quit: Divine (Read error: 110 (Connection timed out)) 23:49:32 well, at best it'll be *really hard* 23:50:18 that really sux 23:50:23 oh well then 23:50:33 wow, the usage of the stack on ppc is strange 23:50:59 there's an interleave there where the callee puts some shit *above* the stack pointer as it was when it was called 23:53:04 does stack grow up or down on ppc? 23:53:39 down 23:53:50 geist, why wouldn't I be able to make sense of the ddk api calls ? 23:54:38 newt: look, dont want to be harsh, but if you really knew what you were doing (which is required to do what you want), you wouldn't be asking this question to an irc chatroom 23:54:55 maybe you have the skills to do it, but I doubt it if you have to ask 23:55:07 oh 23:55:13 --- part: newt left #osdev 23:55:27 well, didn't mean to be mean, but cmon 23:57:14 --- join: Ishq (Ishq@frm-64-4-103-99.access.ntelos.net) joined #osdev 23:57:14 --- quit: MoneyCat (Read error: 104 (Connection reset by peer)) 23:57:15 --- nick: Ishq -> MoneyCat 23:57:15 heh 23:57:51 hmm, so it looks like gcc does some optimization where the stack pointer is always decremented by a multiple of 16 23:58:08 and never uses anything from 0 - 8 from the stack pointer 23:58:28 so the callee has 0-8+ the stack pointer to use 23:58:48 i found this out when I was creating a new stack for a thread 23:59:04 I was setting the stack pointer to the absolute top of it, which on x86 is fine, since a push always predecrements 23:59:17 but in the case of ppc, I have to set it to stack_top - 8 it seems 23:59:23 weird 23:59:26 oh well, learn something every day 23:59:32 how do you create a task, btw? 23:59:42 can you be more specific? 23:59:59 like, what doctoring do you have to do to its new stack? 23:59:59 --- log: ended osdev/03.06.21