00:00:00 --- log: started osdev/02.09.04 00:00:00 thanks for your help 00:00:01 --- quit: codegrrl () 00:00:28 --- quit: malenfant (""must sleep"") 00:00:55 --- quit: yewnix () 00:04:07 --- join: Ricardo (~Rico@145.92.8.40) joined #osdev 00:04:19 air: you here? 00:04:29 yes 00:04:42 good, I'm at uni now. 00:05:02 ok 00:05:40 so, you said that a well written code doen't use more than 4k of stack? 00:05:47 ya 00:06:26 so even if you have dynamic stack growth (just to be sure), it would barely be called? 00:06:43 i wont 00:07:03 okay, "so even if I would have..." 00:07:41 brix wont have ... :) 00:07:57 since it's kinda trival if it really happens, it could fuck things up pretty bad. 00:08:13 its kinda hard to grow the stack 00:08:29 why's that? 00:09:22 the Kos project seems to have it, and if it works, it would be pretty save to prevent big problems\ 00:09:22 gah, had to kill spider on monitor 00:09:31 yuck! 00:09:54 tell me how to do it 00:10:08 I will, if I understand it myself. 00:10:27 is kos sas? 00:11:11 I actually don't know, I only know they have a way of dynamic stack growth. 00:12:02 when u use page faults to catch stack overflow there is no where to grow the stack 00:18:59 so a double fault happens, and with a task gate, the kos project seems to have some piece of code which actually recovers from the stack overflow, though the double fault is an abort. 00:20:00 the document on the sollution is in french, and translating it to english with babelfish helps, but the english isn't really nice. 00:21:09 officially, the intel manuals say that technically there is no way to recover from a double fault, don't know how exactly they explain it, but it's in the kos document. 00:22:09 why would it double fault? 00:24:15 http://kos.enix.org/~d2/snapshots/kos-doc_current/dynamic_stack-html/ 00:24:34 this is another one, in english, it explains it well, I hope. 00:28:55 --- quit: nbsp (Read error: 54 (Connection reset by peer)) 00:29:05 --- join: nbsp (g@ip68-14-60-55.no.no.cox.net) joined #osdev 00:30:15 doesnt explain anything 00:32:01 im guessing that they allocate a bunch of pages for the stack and set the second page to invalid. on a stack fault they alloc more ram and map the second page and set the third to invalid and so on 00:32:33 no, theu use a double fault to recover from a stack overflow. 00:32:49 the double fault using a task gate. 00:32:55 a sas os, especially on a 32bit cpu, has a limited number of pages and cant allocate that many for stack growth 00:33:53 double fault means nothing, im talking about what they do after the DF 00:37:00 you could modify the sp vars and store previous stack pages elsewhere in memory (which are dynamically allocated), which also means that when a stack underflow happens, it needs to reverse the process of the stack page elsewhere in memory 00:37:47 esp register instead of sp vars. 00:38:18 well, actually the esp field in the TSS of the non-double fault handler. 00:40:14 heh 00:40:17 it seems technically completely legible. no special tricks are used to do this, all proper code which should work on any ia-32 cpu. 00:40:34 u would also have to find all pointers on the stack and fix them 00:41:16 finding the pointers is not hard but there is no way to know if its really a pointer or just a value 00:41:57 and the double fault simply returns with an IRET to get the content of the previous TSS data (where the stack has been fixed) and goes on where it went off 00:42:29 what pointers should I find? 00:42:40 and what for? 00:42:45 uhh 00:43:42 lets say i have C function with a char a[100], *p; and i do p = &a; 00:44:10 now u have a pointer to stack data stored on the stack 00:44:42 u gotta search the stack and change the value of p 00:45:04 oh, like that. 00:45:32 but what happens if i have int b; b = p + 1; 00:45:40 b is not a pointer, just a value 00:46:02 but it looks like a pointer cuz its value could be a pointer in the stack space 00:46:12 and then there is the heap problem 00:46:27 which doesnt apply in brix but would in other OSes 00:46:58 say i malloc some ram and store p in there 00:47:13 well, the chance that a stack overflow happens is pretty small. and the fact that code points to a value on the stack a really long way from the esp, is even smaller. 00:47:17 now there is a pointer to stack data stored in the heap and the stack fault would have to find it too 00:47:43 uhh 00:47:56 u must be new to coding 00:49:04 oh yes, I started 3 days ago! 00:49:41 I don't plan to modify the values on the stack. 00:50:55 but I see your problem :) 00:51:05 I'll come back when I have a sollution! 00:51:06 :D 00:51:31 heh 00:51:55 but if kos has it working, I believe it would be possible some way 00:52:04 the stack address cant change 00:52:11 ugh 00:52:20 kos does NOT move the stack 00:52:45 kos is a MAS os and has 4gig of page memory per task 00:53:03 so it can easily set aside a meg of pages for possible stack growth 00:53:15 well, I'll come with a sollution for a sas! 00:53:30 the stack will never move, it will only grow and will never need to have pointers on it fixed 00:53:51 i already have an elegant solution 00:54:04 kill the fat pig :) 00:54:07 well, not a sollution for every sas, just a sollution for my sas-os 00:54:22 but what if it's a critical process? 00:54:33 it wont be 00:54:48 my goal is to be able to prove all code 00:54:56 anyways, I'll TRY to find a sollution 00:55:02 :) 00:55:46 I'll have some ideas that fits with my idea of my os design. 00:56:04 when I have a sollution, I'll document it. 00:57:25 You believe in me, right? 00:57:47 =) 00:58:09 --- join: trans (~trans@216.113.202.59) joined #osdev 00:59:46 btw, u cant use a stack segment cuz its not portable 01:00:20 and i doubt there is any other way 01:01:53 do other architectures suffer from the same problem as the x86? I heared newer architecures have an option to specify a stack to use for a certain interrupt. 01:02:11 air: I'll come back on this, I have class now. 01:02:29 bye 01:03:17 --- quit: Ricardo ("Erection reset by queer") 02:39:19 --- join: corsairk8 (~Stealthy@pc-62-30-121-110-cr.blueyonder.co.uk) joined #osdev 02:49:33 looks like a page replacement livelock/deadlock 02:49:50 hiya wli 02:50:11 re 02:53:01 hmm 02:57:09 --- quit: trans (Read error: 110 (Connection timed out)) 03:03:50 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 03:38:04 --- join: kemu (~kemu@126.125-136-217.adsl.skynet.be) joined #osdev 03:38:09 hi kemu 03:55:03 --- quit: nbsp (Read error: 104 (Connection reset by peer)) 03:55:13 --- quit: trans (Read error: 110 (Connection timed out)) 04:25:25 --- join: DorkPunk (~rajiv@cs6625167-251.austin.rr.com) joined #osdev 04:25:25 --- quit: matricks (Read error: 54 (Connection reset by peer)) 04:25:41 Good morning. 04:29:34 --- join: eirikn (~eirik@ipv6.eirikn.net) joined #osdev 04:36:15 --- quit: kemu (Read error: 104 (Connection reset by peer)) 04:41:43 --- join: kemu (~kemu@126.125-136-217.adsl.skynet.be) joined #osdev 04:52:36 --- join: oink (~ziga@void.phear.org) joined #osdev 04:54:14 --- join: eks (~eks@h24-82-197-140.wp.shawcable.net) joined #osdev 04:54:55 hrm 04:55:03 anyone knows sparc assembly here ? 05:04:28 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 05:05:18 --- join: miro (~miro@pD9E4CE15.dip.t-dialin.net) joined #osdev 05:28:17 --- quit: eks ("Zzz") 05:33:29 --- join: draq (~norm1111a@ESS-p-144-138-43-63.mega.tmns.net.au) joined #osdev 05:46:17 --- quit: trans (Read error: 110 (Connection timed out)) 05:50:53 --- quit: DorkPunk ("BitchX: now with 42 percent more random quit messages!") 05:53:31 --- join: matricks (~asdf@195.58.111.103) joined #osdev 05:54:09 humz 06:08:37 uhm I'm trying to install minix on my old 386, but I first need to format my hd with no filesysteem 06:09:02 so I need a app that boots from floppy and that has fdisk or something like it on it 06:24:36 but the hardest part is the text coloring... the text widget in tkinter is 06:24:40 --- quit: kemu (Remote closed the connection) 06:38:45 --- join: acme (acme@pD9544D2D.dip.t-dialin.net) joined #osdev 06:51:24 grbl 06:54:06 --- quit: Divine ("My damn controlling terminal disappeared!") 06:58:58 --- join: EtherNet (~Under@lu9dcn.ampr.org) joined #osdev 07:01:52 I got cold :( 07:02:30 does anybody want to share it with me ? 07:02:39 no thanks 07:03:05 oink hehehe it's weird.. I thought the cows don't get cold 07:03:49 oink my brother c0w :P 07:04:07 oink I got a song named as: I am cow, I heard it on WOPN Radio, did you listen it ? 07:04:12 I'm aint a cow heh 07:04:15 hrm 07:04:16 no :) 07:05:54 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 07:11:49 --- join: PYRoTkNiX (yeah@d150-53-51.home.cgocable.net) joined #osdev 07:11:49 --- quit: PYRoTkNiX (Remote closed the connection) 07:12:08 --- join: PYRoTkNiX (yeah@d150-53-51.home.cgocable.net) joined #osdev 07:35:53 --- join: eks (~eks@24.70.176.227) joined #osdev 07:37:57 --- join: n3tguy (netguy@217.16.226.189) joined #osdev 07:54:03 --- quit: trans (Read error: 110 (Connection timed out)) 08:09:42 --- join: lynx (~lynx@p50808A92.dip.t-dialin.net) joined #osdev 08:10:53 --- quit: n3tguy () 08:14:19 --- quit: draq (Remote closed the connection) 08:25:28 --- join: tirloni (gpt@neutron.tirloni.org) joined #osdev 08:36:33 --- join: kemu (~kemu@126.125-136-217.adsl.skynet.be) joined #osdev 08:58:27 --- join: jdrake (jptd@CPE014410113717.cpe.net.cable.rogers.com) joined #osdev 08:59:09 --- part: EtherNet left #osdev 09:00:36 i am talking to somebody that doesn't like the idea of having the user code/data mapped to the whole 4gb address space. His concern lies with - how do you protect the GDT? I am not sure. Any ideas? 09:08:53 paging can protect it 09:09:36 --- quit: tirloni ("ircII EPIC4-1.0.1 -- Are we there yet?") 09:13:58 you mean by marking it as not present? 09:22:21 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 09:49:46 jdrake: exact 09:52:40 hey eks 09:52:51 * eks pets lynx 09:53:25 you guys ever use oskit? I am thinking about trying somethings with it, it looks to have everything a kernel would need, and then to get to the real meat 09:53:33 * lynx humps eks 09:53:48 what's oskit ? 09:55:38 http://www.cs.utah.edu/flux/oskit/ 09:55:45 it describes it quite well on the first page 09:55:48 with a diagram 09:58:36 looks kewl 09:58:45 maybe good for learning 09:59:07 hrm 09:59:19 mozilla on 200mhz box = teh suq 09:59:31 well, it runs okay ... but it takes years to load 10:00:38 --- join: dax (~you@u212-239-163-14.adsl.pi.be) joined #osdev 10:00:40 heya 10:00:41 lynx: mozilla loads always slow even on this pc 1.7mhz 10:00:44 hey dax 10:00:51 anyone has some scsi experience? 10:00:54 kemu ? 10:00:57 kemu: which version ? 10:01:01 --- part: eks left #osdev 10:01:18 * corsairk8 has none 10:01:24 i wish someone would write scsi drivers for bochs 10:01:29 Mozilla 0.9.8 10:01:32 kemu: I have a PIII 700/384M on my workstation, and it takes less than a second to load 10:01:35 i wouldnt mind getting some developed 10:01:35 ahh 10:01:38 get the 1.0 :) 10:01:46 kemu: what os? 10:01:48 ohps 10:01:49 mdk 10:01:49 nm :) 10:02:00 Mozilla takes like 5 minutes to load on my 1600xp atlan 10:02:00 kemu : weird. 10:02:07 2 secs here 10:02:07 it's not that it takes like ages to load 10:02:07 corsairk8: get the 1.0 :P 10:02:11 just it takes some secs 10:02:13 i have no idea what version it is 10:02:19 kemu : but it takes too mayn cycles when resizing, so even my mp3 stops for some ms :/ 10:02:24 hehe, you think I would continue to use a system where it took 5 minutes to load a browser? 10:02:30 i loaded windows on it 10:03:06 ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ (: 10:03:09 ie, about 0.05 seconds 10:03:09 corsairk8 : hrm 10:03:27 corsairk8 : so what browser shall i use then? 10:03:27 yeah gonne download mozilla 1.0 10:03:32 lynx :) 10:03:33 hehe, no thanks oink 10:03:37 lynx, whatever browser you want 10:03:38 netscape 4.7 was standard on my irix install 10:03:50 there aren't many browser out 10:03:53 im tired of constantly recompiling software anyway 10:03:55 * lynx nods 10:03:55 that support everything 10:04:03 corsairk8 : i agree 10:04:04 if i cant get binaries, i dont run it, or i dont upgrade 10:04:11 if old versions dont work well, i load something better 10:04:18 corsairk8 : and i dont feel like installing all this gnomeshit on my box for galeon 10:04:26 lol yeh 10:04:36 well, it is shit 10:04:40 lynx: you could try that browser from w3c 10:04:42 if it dont apt-get it dont run on my debian box (thats my motto) 10:04:52 you know.. i have only 2.1gigs in my box and the standard irix takes one gig at least 10:05:14 hrm... 10:05:20 and nfs is slow :/ 10:05:25 irix do they still develop that ? 10:06:30 OF COURSE 10:06:42 why shouldnt they? 10:06:52 irix runs on their high end visualization systems 10:07:15 they just dont release major updates but they improve it and release a new version every 3 months 10:07:30 6.5.16 is out since beginning of august 10:08:08 should what window manager do you use on that ? 10:08:58 --- join: Javanx (~javanx@213.45.18.24) joined #osdev 10:09:39 corsairk8 : the worst thing is when you want to isntall software and you have to tweak the make/configure manually because their scripts suck, heh, i have 3 different elf executables here... and any lib each for it.. the configure scripts go usually crazy and are not able to handle that :/ 10:09:46 kemu : 4dwm 10:10:11 kemu : it is cool, but not so nicely looking, althought it is a really good and useable gui, i luv it 10:10:26 kemu : but there are ppl isntalling kde or gnome on it .... 10:11:59 bah... 10:12:19 is it one of the "no-reply"-days today? 10:18:04 --- join: c0degrrl (~mrng@CPE00a0c5e5b433.cpe.net.cable.rogers.com) joined #osdev 10:19:36 kemu : my freebsd router 10:19:41 :) 10:24:13 --- quit: lynx ("Reconnecting") 10:24:14 --- join: lynx (~lynx@p50808A92.dip.t-dialin.net) joined #osdev 10:25:04 hrm 10:25:08 "Linux is only free is your time is worthless" 10:25:15 beside the flaming linux thing there is much truth in that sentence 10:25:32 you could put *bsd in there, too 10:27:01 are there any devices like a pager that u can send messages from to a phone? 10:27:15 small device 10:27:31 for emergency situations 10:27:38 what do you mean to a phone? 10:27:47 air : you mean cellphone? 10:27:47 there are portable email devices 10:27:51 the device would call someone on a phone 10:28:02 hehe cellphone :) 10:28:24 cellphones are too big 10:28:36 some are pretty small 10:28:46 not small enuf 10:28:55 mine is small :) 10:28:58 very small 10:28:58 if you want to access the phone network, you need... a phone :) 10:29:03 miro: how small? 10:29:08 hrm 10:29:12 screenshot? 10:29:23 snapshot even :D 10:29:25 or it could access another device like it 10:29:35 miro: dimensions 10:29:43 most of a cellphone is battery 10:29:53 air: hrm hold on 10:30:32 miro: less than 2"x2"x.5"? 10:30:51 dunno 10:30:55 air : sure 10:31:29 it's 8x3,5x1,3 cm :) 10:31:40 aeh 10:31:41 8cm is small? :) 10:31:51 yeah 10:31:56 8cm is 3" 10:32:04 10:32:13 the display is 4cm :D 10:32:23 c0degrrl: yes i know 10:32:54 what about a radio system 10:33:12 you want to access the phone network though 10:33:19 push a button on one and the other lights up 10:33:29 hmm 10:33:30 what do you want to do, exactly? 10:33:41 i need to send a signal 10:33:53 over several miles 10:34:07 to what, from what? 10:34:12 the purpose of the signal is constant 10:34:52 i think 2 miles would be max range needed 10:34:58 from what, to what? 10:35:28 i could build it but im too lazy 10:35:39 nevermind 10:35:40 c0degrrl: that dont matter 10:35:42 dont talk to me 10:35:46 ./ignore air 10:43:43 --- join: geist (~geist@tkgeisel.com) joined #osdev 10:53:46 hey geist! 10:58:24 howdy Rico 11:01:17 woo geist 11:05:03 indeed 11:05:41 (^_^) 11:06:15 lol 11:06:26 (^_^) <- that's lynx on drugs 11:07:22 ^^^(*.*)^^^ *kra* <-- miro as usual 11:08:25 hmm, interesting 11:08:53 :| 11:09:09 lynx: not miro 11:09:12 lynx: Robert 11:09:15 lol 11:10:16 * lynx nods, expressing enlightment with a fabulous gesture 11:18:45 starship poopers on tv 11:18:52 poopers ? 11:18:55 boobers ? 11:19:05 tits ? 11:20:53 no 11:21:00 poo 11:21:15 you know... the stuff the french kids prefer playing with 11:21:40 indeed 11:22:16 geist : how is your dev stuff going? 11:22:23 it's going 11:22:48 I started hacking around with my ppc last night again 11:22:56 but I bumped into a problem with varargs and ppc 11:24:06 what problem? 11:25:01 the varargs implementation I stole is out of date with respect to gcc 3.x 11:26:09 oh 11:27:09 so I'll probably steal another implementation, probably from netbsd since that's in sync with my license 11:28:48 =) 11:30:14 --- quit: corsairk8 (Read error: 104 (Connection reset by peer)) 11:30:33 --- join: corsairk8 (~Stealthy@pc-62-30-121-110-cr.blueyonder.co.uk) joined #osdev 11:31:50 --- join: tirloni (gpt@neutron.tirloni.org) joined #osdev 11:53:03 --- quit: corsairk8 () 11:53:13 mmm 11:53:25 my desktop is mmmmmmmmmmmmmm 11:54:09 and i'm going to setup my OWNAGE SMP box soon. 11:55:10 hrm 11:55:40 geist : would you either buy an octane r12k@300mhz or a dual r10k@250mhz ? 11:56:18 well, since I already have a mips box (sgi indy r5k, I'd go for the dual 10k) 11:56:47 no r12k ? 11:56:57 i am not sure if the r12k is better/faster 11:57:08 maybe, but I'd want a dual 11:57:18 dual r12k >:) 11:57:41 that's not an option according to your list 11:57:48 and look up the specs on theose two cpus 11:58:00 well, i have to save money anyway 11:58:01 find out the real difference (deeper pileline, more cache, etc) 11:59:32 hrm 11:59:55 anyone knows if it's possible to directly access the pc register w/ sparc ? 12:00:05 --- join: bono (~bono@modemcable171.3-202-24.mtl.mc.videotron.ca) joined #osdev 12:00:12 not sure, it's not a gpr so maybe not 12:00:21 pc register? 12:00:27 it's not 12:00:29 bono : hey :) ! 12:00:35 hey lynx 12:00:44 program counter 12:00:47 bono : i lost my src AGAIN :/ 12:01:02 lynx: use a cvs you #!@$!#$@ 12:01:13 bono : server&indigo crushed at me... the only thing that is left are some backups from 26th 12:01:17 oink : yes :/ 12:01:38 * lynx compiling wxMotif 12:02:37 I'm trying to do something like 'stb %o5, [%pc + 7]' 12:02:44 but I can't :\ 12:04:13 ohhh 12:04:19 oh? 12:04:24 seems like %pc is available only with v9 architectures 12:04:26 crap 12:04:46 rd I meant. 12:04:48 setreuid.asm:14: Error: Architecture mismatch on "rd". 12:04:49 setreuid.asm:14: (Requires v9|v9a|v9b; requested architecture is sparclite.) 12:07:00 --- part: witten_ left #osdev 12:07:13 oink : what sparcbox do you have? a lunchbox? 12:07:35 ultra60, ain't mine 12:08:06 gonna look for one on december 12:08:19 * file is back 12:08:42 =) 12:08:50 well 12:08:59 i am out, later babes 12:09:01 take care 12:09:17 --- join: kaze (~kaze@bordeaux-2-a8-62-147-54-38.dial.proxad.net) joined #osdev 12:09:44 * file is not a babe 12:12:45 --- part: oink left #osdev 12:13:35 --- quit: kaze (Remote closed the connection) 12:17:35 --- quit: jdrake () 12:19:31 --- join: Ghiottone (~alex@ppp-243-9.27-151.libero.it) joined #osdev 12:20:09 --- nick: geist -> geist-towork 12:30:15 --- quit: PYRoTkNiX ("syntax: Desperate plea for sanity") 12:36:52 --- join: PYRoTkNiX (yeah@d150-53-51.home.cgocable.net) joined #osdev 12:37:16 --- part: PYRoTkNiX left #osdev 12:38:31 --- join: Ghiottone_ (~alex@ppp-243-9.27-151.libero.it) joined #osdev 12:38:47 --- quit: Ghiottone (Read error: 60 (Operation timed out)) 12:39:00 --- nick: Ghiottone_ -> Ghiottone 12:46:36 --- join: eks (~eks@h24-82-197-140.wp.shawcable.net) joined #osdev 12:57:32 --- part: Ghiottone left #osdev 13:10:38 --- join: HuntrCkr (~huntrckr@myr53-01-p34.gt.saix.net) joined #osdev 13:12:23 --- quit: gab (Read error: 104 (Connection reset by peer)) 13:12:33 hello? 13:12:53 --- join: gab (~prfalken@gaia.chx-labs.org) joined #osdev 13:12:58 * eks waves to HuntrCkr 13:13:32 * HuntrCkr waves back :) 13:14:44 hehe, finally have just about everything running in Gentoo... just need to get a proper web browser installed, and i done 13:16:46 btw, anybody using kde, do you figure it would be possible to use KDevelop as a enviroment for OS programming? 13:17:46 hmmm... nevermind... seems everyone is busy... 13:18:06 * HuntrCkr will go to sleep and see about KDevelop in the morning 13:18:16 * HuntrCkr is away: I'm busy 13:18:40 --- nick: HuntrCkr -> HuntrCkr_away 13:25:56 --- quit: miro (Read error: 110 (Connection timed out)) 13:38:07 --- join: kemu_ (~kemu@126.249-136-217.adsl.skynet.be) joined #osdev 13:42:48 --- quit: Spindle (Read error: 104 (Connection reset by peer)) 13:49:15 --- join: DRF (~daniel@host213-121-69-48.surfport24.v21.co.uk) joined #osdev 13:49:37 --- join: kemu__ (~kemu@22.125-136-217.adsl.skynet.be) joined #osdev 13:54:10 --- join: Zn4k (~zn4k@cs243169-153.jam.rr.com) joined #osdev 13:54:19 --- part: Zn4k left #osdev 13:54:37 --- quit: kemu (Connection timed out) 14:02:48 --- join: pavlovski (TimRobinso@modem-86.abra.dialup.pol.co.uk) joined #osdev 14:02:59 hi all 14:03:16 --- join: Spindle[IntelDoc (~SpindleTe@12-249-145-77.client.attbi.com) joined #osdev 14:03:40 so then i says to the clown i says your not a clown the clown said yes i am -- true story =) 14:06:07 --- quit: kemu_ (Connection timed out) 14:06:37 --- quit: tirloni ("ircII EPIC4-1.0.1 -- Are we there yet?") 14:08:42 --- join: Kurt (~kmw@gc-nas-01-s160.cinergycom.net) joined #osdev 14:08:43 --- quit: Spindle[IntelDoc (Read error: 104 (Connection reset by peer)) 14:14:46 --- quit: eirikn (Remote closed the connection) 14:26:13 --- join: corsairk8 (~Stealthy@pc-62-30-121-110-cr.blueyonder.co.uk) joined #osdev 14:26:45 --- nick: kemu__ -> kemu 14:27:01 blah? 14:27:42 --- nick: geist-towork -> geist 14:30:05 --- join: Spindle[IntelDoc (~SpindleTe@12-249-145-77.client.attbi.com) joined #osdev 14:33:15 --- quit: corsairk8 () 14:37:02 uggg 14:37:11 i am still in the toc for intel vol 3 14:37:12 lol 14:37:48 have fun 14:42:03 yippe! chapter one! 14:42:10 * Spindle[IntelDoc dances 14:43:49 * pavlovski parses STABS debugging info :( 15:09:36 --- join: wossname (wossname@HSE-QuebecCity-ppp81952.qc.sympatico.ca) joined #osdev 15:11:36 boltion: stat() 15:21:48 --- nick: DRF -> DRFaway 15:29:07 got a q 15:29:28 has any os yet developed directly map unused pages of memory to disk space? 15:32:53 eh? 15:33:23 what would that accomplish? 15:33:26 whenever the memory is accessed, the page isn't loaded so the kernel loads it into disk cache and.. 15:33:43 abstracts the system 15:33:50 in other words, the os uses unused pages as a disk cache? 15:33:57 it uses it _as_ the disk 15:33:58 witten's os, along with many others, maps the entire 4gig to the drive 15:34:16 the disk's interface is the memory 15:34:28 that's not terribly convienient 15:34:34 on? 15:34:37 er, no? ;p 15:34:49 the disk interface is a lot more restrictive than actually dealing with memory directly 15:35:23 hrm? 15:35:37 wossname: i think yer talking about persistence 15:36:18 wossname: u dont wanna deal with the drive right? 15:36:33 yeah, i just want to read a byte off of it with no trouble 15:36:34 no loading of files and such 15:36:46 so it sounds like you want to map the disk to memory 15:36:48 i want to hide all the difficulties behind an abstraction 15:36:54 ok, witten is doing that 15:37:17 trouble is that doesn't work that well on 32-bit systems 15:37:24 i know 15:37:26 since you dont have much space. it's a lot more plausible on a 64-bit system 15:37:35 i thought of i read about the ia64 15:37:36 u can use pointer swizzling 15:37:46 too much addressing space ;P 15:37:49 though the overhead of storing the mappings in a relatively sparse way is a bit complex 15:38:05 but that's a pretty viable way to do it 15:38:08 * file returns 15:38:28 i'd like to write a half-os that just provides this layer of abstraction 15:38:36 have at it! 15:38:37 i dont agree with it tho 15:38:49 i'll wait for intel to release the ia64 manuals in paperback ;D 15:38:57 the os itself is designed so u can have pointers to anything 15:38:58 buy an ultrasparc 15:38:59 for that matter, when i can get my hands on a system running it 15:39:17 you can buy an ia64 now 15:39:27 they just aren't cheap 15:39:32 and aren't likely to get cheap any time soon 15:39:52 well... when i can get my hands on it ;P 15:40:05 in fact, not much good to do that stuff until a lot of people can get their hands on it 15:40:33 yep 15:40:34 --- quit: pavlovski (Read error: 110 (Connection timed out)) 15:40:43 also it wouldn't be that efficient on a x86-64 15:40:56 much more effective on a explicit TLB based system 15:41:12 i don't know any of the details of paging for the new architecture 15:41:21 i'm still stuck in a 32-bit world 15:42:06 i have these pdfs lying about, but pdfs suck 15:42:24 I dont know, they sure beat a book when using it as reference 15:42:33 a book is nice when you initially read it 15:43:16 ... and? 15:43:37 --- quit: kemu (Remote closed the connection) 15:43:50 what? 15:44:19 you can take a book anywhere 15:44:42 okay fine 15:44:45 pointless argument 15:44:49 ;P 15:45:44 * file is back from the room where water falls 15:45:58 anyway, the concept of just memory mapping everything isn't new 15:46:08 the solaris vm is built around that concept quite a bit 15:46:26 the vnode is pretty much the base object for most vm objects 15:46:45 and they designed that back in the 80's 15:46:57 it may not be new to the rest of the world, but it still seems neat. 15:47:13 i can't see what's wrong with it, aside from the overhead 15:47:24 --- quit: Kurt ("Connection reset by ear") 15:47:28 overhead is a lot 15:47:35 I'm not sure what's gained from doing that 15:47:56 what overhead? 15:48:06 the overhead of keeping a mapping that large 15:48:08 u eliminate all code that deals with files 15:48:19 data structures to store such a sparse mapping 15:48:20 if you write a nice base around the whole thing, developing on top should be a cinche 15:48:34 but it wouldn't be as bad on a lot of architectures 15:48:54 also there's a security issue, anything can get to anything on your disk 15:49:14 safe language 15:49:14 and code that goes awol has a much greater chance of hosing the contents of the disk 15:49:14 you can use processor memory protection 15:49:39 it's just the 'operating system' on top of the layer that needs direct access.. 15:49:52 everything else can deal with that 15:50:04 * geist shrugs 15:50:06 go for it 15:50:10 sounds like fun 15:50:38 I think in a limited fashion that could be pretty darn useful 15:50:59 lots of caching VMs do a subset of that, by essentially memory mapping 'files' onto kernel space 15:51:30 removes a lot of the complexity of the lower level caching system, and integrates the memory/cache management into a single code base 15:51:57 also, that has the benefit of caching at a higher level the files in the system 15:52:13 which is a big deal for file systems that have compressed files 15:52:17 or are network based 15:52:26 things will be _cleaner_ :) 15:52:29 so by caching the logical contents of the file by memory mapping 15:52:32 but code still needs to be aware that there is a disk below 15:52:50 that is true, just as code has to be aware that the file is on another computer for example 15:53:10 one of the problems I can see with just mapping the disk to memory is it doesn't take care of what to do about remote file systems 15:53:22 the mp3 player would need to make dummy accesses to the data ahead of time to force it to load 15:54:08 by mapping at a higher level, and say only exposing to the 'applications' the concept of memory mapped files, you get rid of some of the problems I see 15:54:44 so for example by removing the concept of read/write calls to the 'applications' (user space or safe language or whatever) and exposing to them memory mapped files 15:54:54 you get around security, network transparency, etc 15:54:59 but still get the vm integration 15:55:16 but the os still has to know how to read/write to the disk or network or whatever 15:55:21 hrm.. :/ 15:55:21 what that 10gig database file? 15:55:24 but I dont see a waya round that. you have to do it eventually 15:55:27 what about.. 15:55:41 yeah, but that 10gig database file has to reside on a > 10gig disk 15:55:54 i'd rather have the kernel do all of that, the system built around it to deal with memory and the apps to deal with the system 15:55:55 I'm proposing this as an alternative to mmemory mapping the entire disk 15:56:08 wossname: that's the point, the kernel handles the mapping of files to memory 15:56:09 but u cant map that file into a 32bit address space 15:56:24 i like the idea of mapping an entire disk in memory 15:56:26 no, you have a problem with 32-bit address spaces no matter what you do when you are dealing with memory mapped anything 15:56:29 --- join: tirloni (gpt@neutron.tirloni.org) joined #osdev 15:56:46 it's certainly possible for a test-os running off floppy ;D 15:57:14 wossname: maybe thats why none of them have left the research lab :) 15:57:20 right 15:57:49 but basically exposing to the applications the mmory mapped file directly is just an evolutionary design based off how most caching vms work now anyway 15:58:09 since most of them simply keep a mapping of the file in kernel space and simply memcpy it to the user space buffer when you ask for a read/write 15:58:31 or target buffer or whatever you want (if you are SAS) 15:59:14 well, for me reading and writing would still be a read() and a write() 15:59:20 oh? 15:59:31 then what's the point? 15:59:43 dammit, that question is so annoying :( 16:00:01 the point is the cleanliness of the operating system 16:00:04 no, I mean mapping the disk to memory and still using read()/write() doesn't really accomplish anything 16:00:13 oh, well that's how most of them work already 16:00:15 sorry to dissapoint 16:00:32 i believe if an os is written on top of that, it can be made much simpler (and bug-free) 16:00:41 they already do 16:00:45 well, all the x86 ones in my loser x86 land don't seem to do that :( 16:00:54 NT does 16:01:09 it's caching structure works roughly that way 16:01:12 it doesn't have enough addressing space, though? 16:01:28 doesn't matter, it only has to map in chunks of the disk at a time 16:01:41 ie, you ask for a chunk, it returns a pointer to it 16:01:47 i just want to map it all in 16:01:47 you release a ref on the chunk 16:01:58 okay, that's the same thing 16:02:09 the operating system, when started will be able to read some info at memory location 0 and see the entire status of the system and where it's bits have been mapped 16:02:19 if whatever you are mapping is smaller than the total amount of chunks you can have in memory at the same time, then you accomplish the same thing 16:02:43 hrm, okay 16:03:15 well, I'm not saying you can't do it at all. Not trying to put the idea down, I'm just examining it in detail to see what the benefits/drawbacks are 16:03:30 i know, a gigantic amount of paging space lost for one.. :( 16:03:31 the obvious drawback is the limitation of what you can map and the overhead in page tables (on x86) 16:03:43 on the x86-64, i can use different page sizes, right? 16:03:48 nope 16:03:58 x86-64 just extends the paging structure to go to 4 levels instead of 2 16:04:04 so it has the same overhead 16:04:07 ah :/ 16:04:14 always fixed 4k pages, eh? 16:04:19 and 4MB 16:04:23 but yes 16:04:24 oh? 16:04:32 but for protection purposes, it's still insane 16:05:06 so the overhead is if you map a huge file into memory and touch memory ever 4MB, you have to allocate a page for the new page table in addition to the page you ahve to bring in 16:05:18 * file twitches 16:05:35 so in that case you get 50% utilization 16:05:40 but that's the worst case 16:05:51 i thought they'd have reasonable, in between page sizes :/ 16:06:03 the best case is you only touch pages within a 4MB region of virtual space, in which case that will require just a single page table (4k) 16:06:14 so you get a 4096/4097% utilization 16:06:25 so, i can treat things as 4 megabyte pages 16:06:31 until the space is actually touched 16:06:36 when i have to submap them? 16:08:34 heh, i'm lost 16:09:19 i'll just grab 16 gig of ram when i go to code my system, and make sure it's a terahertz processor 16:10:46 WOO 16:11:01 food tastes good 16:14:35 booooring. 16:14:56 ^_________________________________________- 16:18:35 * geist needs to get to work 16:18:37 later 16:18:38 --- part: geist left #osdev 16:29:06 --- quit: wossname ("LOR") 16:41:20 --- join: oink (~ziga@void.phear.org) joined #osdev 16:41:24 boo 16:46:40 does anyone know when they'll be shipping ia64 comercially ? 16:46:57 Who? 16:47:05 AFAIK NEC & HP are already doing so. 16:47:06 intel 16:48:21 tirloni: you plan to buy one ? :) 16:48:57 anyone knows how to fetch a pc from a sparc V8(-), ? 16:49:14 oink, no :) 16:50:17 tirloni: no, there is no way or, no, nobody ? :) 16:50:53 no, I don't think I've any money to spend now 16:51:07 ah 16:51:09 :) 16:51:53 --- quit: BrightDude (Read error: 110 (Connection timed out)) 16:52:52 I thought Intel was only giving some ia64's to developers.. 16:53:51 bah 16:53:52 'some' ? :) 16:53:59 like 10 ? :) 16:54:24 hrm.. they had enough money to send me free manuals.. 16:54:47 well, I think you understood :) 16:55:40 :> 16:55:43 * oink compiles gdb 5.2.1 16:56:02 5.0 doesn't seem to support 64bit stuff. 16:58:14 --- quit: trans (Read error: 110 (Connection timed out)) 16:58:50 nite 16:58:59 (-_-)zZzz 17:02:51 oink : intel sends printed manuals? 17:04:31 * file finishes his algebra homework which isn't due till Friday 17:05:35 oh American Idol is on... 17:05:45 Big Brother isn't till 10... :| 17:06:00 say analysis, sounds better than algebra :P 17:06:10 and yes, intel sends hardcopies of their manuals 17:06:21 hardcopy* 17:06:22 blah 17:06:34 http://developer.intel.com/ 17:06:44 or something 17:11:12 file: u actually watch those shows? are u a retard or what? 17:11:31 I like to laugh at them 17:12:02 laugh? they make me sick 17:12:07 hehe 17:12:14 it's a great example of how people truly are 17:12:20 inside we're all EVIL! 17:13:45 except pikachu 17:13:47 pikachu isn't evil 17:14:09 pikachu is teh bestz0r. (c) Robert 17:14:22 heh 17:14:58 PUCHUU 17:18:18 hey 17:18:28 * file waves to fraggle 17:18:30 ermph 17:18:32 wrong channel 17:22:17 --- join: Zn4k (~zn4k@cs243169-153.jam.rr.com) joined #osdev 17:23:39 what are C++ exceptions like? 17:23:49 cuz lisp exceptions are 100 times faster 17:23:55 ? 17:24:12 everything depends on the compiler... 17:24:14 and i dont see how anything could be 100 times faster unless C++ sucks really bad 17:24:41 --- quit: DRFaway ("Nite Nite") 17:26:22 fuck it 17:27:17 I finished compiling gdb 5.2.1 and it still complains when I try loading a 64bit executable 17:30:52 --- quit: Javanx ("I don't feel a thing, and i stopped remembering. The days are just like moments tourned to hours") 17:31:13 --- join: BeFree (~BeFree@Mix-LeMans-210-1-184.abo.wanadoo.fr) joined #osdev 17:31:36 Hi all 17:31:42 woo i read almot 5% of doc 17:36:42 --- quit: oink ("l'info, la merde") 17:43:59 hi 17:46:34 --- quit: c0degrrl () 17:57:03 Spindle[IntelDoc, what re you reading? 17:57:56 --- join: c0degrrl (~abc@CPE00a0c5e5b433.cpe.net.cable.rogers.com) joined #osdev 17:57:59 woo 17:58:27 on linux, lets see if i can get something to compile 18:04:03 nobody is around? 18:05:09 good night 18:05:12 --- quit: tirloni ("ircII EPIC4-1.0.1 -- Are we there yet?") 18:06:40 --- quit: gpf|venus ("Client Exiting") 18:07:23 --- quit: BeFree (Read error: 110 (Connection timed out)) 18:10:25 --- join: nbsp (g@ip68-14-60-55.no.no.cox.net) joined #osdev 18:10:57 --- join: Stalky (~cms@ool-4352c2ce.dyn.optonline.net) joined #osdev 18:11:04 hello 18:16:54 --- join: BrightDude (~garetht@pc-80-193-35-25-lp.blueyonder.co.uk) joined #osdev 18:18:00 --- join: ChillySpy (ChillySpy@ppp011.ppp1.cleveland.nccw.net) joined #osdev 18:23:36 compile :---( 18:25:23 ld: target coff-go32 not found 18:26:35 --- quit: ChillySpy () 18:29:38 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 18:29:51 @_@ 18:31:45 ! 18:32:14 now i have two .o files, but i can't link them 18:32:32 i've noticed something 18:32:52 the difference between my code and other peoples code, is that my code compiles and links 18:33:29 then how interesting can it really be? 18:35:06 its useful 18:39:28 --- quit: c0degrrl ("Client Exiting") 18:58:04 --- join: stormbind_ (~stormbind@pD9519E9A.dip.t-dialin.net) joined #osdev 18:58:54 --- quit: stormbind (Connection timed out) 19:00:20 gn all 19:01:05 does anyone know spanish 19:23:21 Spindle[IntelDoc: si, yo hablo español 19:23:50 yippe 19:24:10 whats 19:24:27 compartir un pasatiempo mean =P 19:25:35 ok, let share it ;) 19:25:37 aagh 19:25:45 * indigo thinks he may have figured out why io won't work 19:25:59 it might be a gcc bug (of course) 19:26:03 fscking gcc 19:26:18 hum 19:26:27 anyone have a working gcc 3.1 system? 19:26:33 * indigo looks at gentoo people 19:30:11 * Zenton goes to bed ZzZzzzzz 19:31:00 does anyone have a gcc 3 system? 19:33:46 --- join: malenfant (~malenfant@ati2362cy13e4.bc.hsia.telus.net) joined #osdev 19:40:15 --- quit: trans (Read error: 110 (Connection timed out)) 19:47:11 i'm running gcc 3 19:47:19 not 3.1 tho 19:47:47 haven't encountered any bugs 19:48:09 though optimization had problems w/ my inline assembly when i didn't specify clobbers correctly 19:59:18 --- join: DorkPunk (~rajiv@cs6625167-251.austin.rr.com) joined #osdev 20:00:43 --- quit: eks ("zzzz") 20:05:24 hm 20:06:09 gcc 3.0 then? 20:06:29 this bug existed in 3.0.4, aparrently 20:07:33 3.0.4, yes 20:07:39 :/ 20:07:42 redhat 7.2's gcc3 package 20:07:49 ah 20:07:53 that's exactly what the bug was in 20:08:00 what is it? 20:08:11 http://gcc.gnu.org/ml/gcc-bugs/2002-07/msg00720.html 20:08:20 problems with dynamic_cast<> 20:08:22 thank you 20:08:25 ah 20:14:27 i've had rtti disabled in my project, which is the only real exercise of gcc 3 i've done 20:15:10 I'll settle for C and hack around the genericity problems. 20:15:34 --- quit: Zn4k () 20:15:37 I can't figure out how the heck to remap these bridges anyway, it's more or less hopeless. 20:15:57 ? 20:17:54 b = reinterpret_cast(&goldenGate); 20:18:20 ?? 20:18:44 ! 20:18:51 ¡ 20:19:19 ¿? 20:19:27 umop apisdn 20:19:29 ¶ 20:19:45 ¶: <--- fat lipped drooling smilie 20:19:53 haha 20:20:03 wo hehe 20:20:55 --- join: sbk_ (~kbs@dsl-65-184-98-221.telocity.com) joined #osdev 20:30:10 --- quit: acme (Read error: 104 (Connection reset by peer)) 20:37:34 well, let's see how tiobench 16384 does with nonblocking get_request_wait(). 20:41:28 --- quit: nbsp (card.freenode.net irc.freenode.net) 20:41:28 --- quit: Spindle[IntelDoc (card.freenode.net irc.freenode.net) 20:41:28 --- quit: gab (card.freenode.net irc.freenode.net) 20:41:28 --- quit: HuntrCkr_away (card.freenode.net irc.freenode.net) 20:41:28 --- quit: bono (card.freenode.net irc.freenode.net) 20:41:28 --- quit: lynx (card.freenode.net irc.freenode.net) 20:41:28 --- quit: matricks (card.freenode.net irc.freenode.net) 20:43:39 --- join: gab (~prfalken@gaia.chx-labs.org) joined #osdev 20:43:40 hum 20:43:58 --- join: bono (~bono@modemcable171.3-202-24.mtl.mc.videotron.ca) joined #osdev 20:44:00 * indigo wonders if it's worth checking for failed memory allocations in the kernel 20:44:15 indigo: required. 20:44:23 why's that? 20:44:44 what will it do, exit gracefully with an error message? :P 20:45:03 the kernel allocator will try to make more memory if it runs out... 20:45:07 but if it can't, well... 20:45:27 not much more I can do than shut down the system as cleanly as possible 20:45:28 --- join: Spindle[IntelDoc (~SpindleTe@12-249-145-77.client.attbi.com) joined #osdev 20:45:28 --- join: HuntrCkr_away (~huntrckr@myr53-01-p34.gt.saix.net) joined #osdev 20:45:28 --- join: lynx (~lynx@p50808A92.dip.t-dialin.net) joined #osdev 20:45:28 --- join: matricks (~asdf@195.58.111.103) joined #osdev 20:45:49 hm... 20:45:51 even that wouldn't be possible 20:46:15 gotta have memory to shut down... 20:46:36 * indigo decides a kernel panic is the best solution 20:46:56 wli: you agree, or am i missing something? :P 20:47:11 * indigo assumes wli agrees 20:47:33 kernel panics aren't the best solution 20:47:42 well, what else could i do? 20:47:50 the allocator will try to make memory by: 20:47:57 1) flushing disk caches 20:48:03 2) creating swap space 20:48:08 3) killing processes 20:48:25 maybe there's more... 20:48:46 but anyway, if the kernel allocator can't make memory, there's nothing I can do except lock 20:48:58 there's no way to recover, because there isn't any memory :) 20:50:34 ja? 20:50:44 you could reserve enough memory for a clean shutdown 20:50:54 that might force the shutdown earlier than otherwise tho 20:51:06 yes, but that would be inside the allocator 20:51:26 i'm just wondering if i should have the allocator return an error and check it every time i allocate 20:51:31 seems pointless 20:52:17 --- quit: malenfant ("Client Exiting") 20:52:23 for a cleen shutdown all i 20:52:24 oetnah 20:52:31 for a cleen shutdown all that's needed is to unmount the disks 20:53:00 and actually, the caches will already be flushed, so even if they wern't unmounted there would be no damage, just a check at boot 20:53:53 so, just panic then 20:54:40 right :) 20:56:41 --- quit: sbk_ ("Leaving") 21:00:35 hm...midnight 21:00:43 2002-09-05T00:00:43-0400 21:00:55 good morning everyone 21:01:10 --- quit: DorkPunk ("BitchX: often imitated, never duplicated!") 21:01:39 --- join: trans (~trans@fatwire-202-58.uniserve.ca) joined #osdev 21:02:10 indigo: where do you live? 21:02:17 michigan, usa 21:02:32 where did you expect? :P 21:04:06 heh 21:04:07 silly me 21:06:11 hi 21:07:10 'lo trans 21:07:41 what up Stalky 21:08:50 not much 21:08:53 broke everything 21:08:56 trying to fix it now 21:08:59 ? 21:09:25 i added a new kind of shared memory; instead of just sharing pages, multiple processes can share page tables 21:09:34 so i switched some stuff over to use this 21:09:39 and it gpfs all over the place 21:09:53 ah 21:09:55 fun 21:10:04 plan9 had something like that 21:10:09 has, rather 21:10:36 i'm using shared memory extensively 21:10:41 all the page tables were getting expensive 21:10:54 i wonder if it will cause me grief if i ever want to port 21:10:58 Stalky: well, remove the pagetables. 21:11:05 hum 21:11:12 * indigo is tired and can't think, so he's going to bed 21:11:16 i'm pretty well committed to page tables at this point 21:11:32 Stalky: it's easy 21:11:47 i'm in the middle of writing a really complex function...hopefully my comments will give me a clue in the morning :P 21:11:57 Stalky: first off, they can be shared most of the time 21:12:09 Stalky: second, you can also just remove them most of the time 21:12:19 Stalky: third, when you can't just remove them, you can swap them 21:12:57 Stalky: but you shouldn't keep anything besides memory in the pagetables, keeping swap info and/or disk block info in them is evil 21:13:57 what else should you put in not present ptes? 21:14:38 The number zero. 21:14:45 And if the pagetable is completely empty, free it. 21:14:53 bah 21:15:23 Swap information is best kept elsewhere, where it can be shared. 21:18:10 Then you just ask machine-dependent code to find some pagetable that'll do the right translation etc. and it caches hashes shares etc., possibly even uses 4MB pages on i386 and so on and so forth. 21:19:04 i see no reason to waste the pte in x86 21:19:06 that's silly 21:19:10 On things like PPC you don't bother keeping pagetables at all. 21:19:51 i'm hoping by the time i get to a mac port, apple will have ditched those slow things 21:19:54 they may be nicer 21:19:56 The pte on i386 is a problem, not a solution. It's better to treat swappable regions like files. 21:19:59 but it would make for an easier port 21:20:39 Easier port of what? 21:21:06 --- join: karingo (karingo@199.portland-13-14rs.or.dial-access.att.net) joined #osdev 21:22:11 --- join: malenfant (~malenfant@ati2362cy13e4.bc.hsia.telus.net) joined #osdev 21:22:48 eh, nothing even worth discussing porting yet 21:22:52 some memory mgmt & ipc code 21:31:43 --- quit: bono ("leaving") 21:36:47 --- quit: karingo () 21:38:19 g'nite 21:38:20 --- quit: Stalky ("http://www.echosproject.org") 21:44:51 hmmm... 21:46:14 if say there were gui drivers and support and that sort of stuff in the kernel, would it be benificial (even in the least) to be able to have more than one interface to a gui system? 21:56:27 --- quit: HuntrCkr_away (Read error: 110 (Connection timed out)) 22:06:18 --- join: karingo (karingo@199.portland-13-14rs.or.dial-access.att.net) joined #osdev 22:09:16 --- join: nbsp (g@ip68-14-60-55.no.no.cox.net) joined #osdev 22:29:38 MORNING! 22:39:13 g'morning lynx 22:41:07 --- quit: karingo () 22:43:15 --- join: geist99 (~geist@dsl-65-191-44-105.telocity.com) joined #osdev 22:43:28 --- nick: geist99 -> geist 22:47:46 --- quit: trans (Read error: 110 (Connection timed out)) 22:56:32 any gdb experts around? 22:57:58 hey malenfant :) 22:58:12 hey geist 22:58:18 s/hey/woo 22:58:31 hrm 8 in the morning... 22:59:03 11 pm here 22:59:49 same here 23:00:05 pff... the living-in-the-past-guys... 23:01:33 hrm 23:01:42 what are you dudz going? 23:01:48 err doing 23:01:54 * lynx still asleep 23:01:58 trying to figure gdb out :) 23:02:16 ask geist =) 23:04:34 ,,, i think i figured it out now :) 23:05:26 I dont know anything about gdb 23:05:32 never really used it 23:05:52 do you use a debugger? 23:06:06 not usually 23:06:28 only time I ever use an interactive debugger is when I'm developing a windows app or something like that 23:07:03 most of the large scale projects I've worked on dont have any sort of interactive debugger support 23:07:20 i'm making a GUI app using wxWindows... so kinda like windows 23:07:50 do you use printf's or logfiles or something? 23:08:15 most of the time yes 23:08:25 some form of printf or panics in key locations, etc 23:08:41 most of the serious work I've done has been on some sort of kernel or os 23:08:50 and it's hard to have interactive debugger support for that 23:09:34 malenfant : i am doing wxwindows stuff right now, too :P 23:09:40 i can't imagine what it must be like to debug a large os 23:09:50 it's a big pain in the ass 23:09:51 lynx: yes, i see you in #wxwindows 23:10:03 well... ppl hardly talk there 23:10:04 basically you need to get it right the first time, and be very good and figuring things out 23:11:53 debugging a threaded OS must be hell too... it's hard enough /with/ a debugger 23:13:05 hmm... does gcc have a 64 bit integer data type? 23:13:31 long long for 32-bit procs 23:13:45 long long was later adopted as the official standard for c99 23:14:22 cool, thanks 23:15:03 on a 64-bit proc, long long == 64-bits, long == 64-bits 23:16:06 -- warning: ANSI C++ does not support `long long' -- is there a 'proper' one for C++? 23:16:17 guess not 23:16:30 long long is a gcc extension 23:16:48 ie, in c and c++ there is not a 64-bit type, since the official spec only goes through long 23:17:07 oh well.. it's temporary code anyways.. i'm gonna take it out later 23:17:27 oh an this is on gcc I assume 23:17:35 visual C for example uses __int64 I think 23:17:53 geist : what is an IPL ? 23:18:39 in the context of interrupt descriptors? 23:18:50 yeah, this is gcc.. i think win32 also has a ULARGEINTEGER which is probably another typedef for __int64 23:18:53 interrupt priviledge level I think 23:18:53 well... 23:19:19 geist : a guy used that term when he descibed the qnx booting on his dreamcast 23:19:32 oh 23:19:38 s/the// 23:19:40 how did he use it? 23:20:22 oh I see 23:20:23 hmm 23:20:29 he used it in connection with the bios/serial driver 23:20:34 --enable-long-long 23:20:38 --enable-c99 23:20:44 hmm 23:20:48 The "long long" type was introduced in C99, along with many other functions for wide characters, and math cl 23:20:51 some sort of initial something 23:20:56 Interrupt Privilege Level 23:20:57 anyway, trivial! 23:21:11 yes, but that's not what this guy is talking about 23:21:20 long long **IS** part of the spec, not a gcc extension 23:21:25 Instruction Level Parallelism? 23:21:25 air: yes, but gcc has been supporting long long for a long time 23:21:31 it just became official in c99 23:21:46 but I dont think it's part of c++ technically, since they haven't released a new spec yet 23:21:59 lots of previous gcc extensions made it into c99 23:22:00 ie, in c and c++ there is not a 64-bit type, since the official spec only goes through long 23:22:09 you know what I mean 23:22:17 wli : i dunno ... just look on osnews.com 23:22:17 I even stated that in c99 it's official 23:22:59 anyway, the dude didn't even have to write the os 23:23:16 some guy wrote in saying 'wow, that was quick. the linux people take months to port it!. 23:23:17 ' 23:23:35 duh, the qnx kernel was already ported to sh, he just got it loading on that particular board 23:23:43 the dreamcast is pretty straightforward 23:23:48 nothing really funny going on 23:25:13 it's pretty fun to hack code on, though writing asm for the sh is kind of painful 23:25:32 hrm 23:25:48 geist : you ported your kernel to dreamcast, too? 23:25:52 yeah 23:26:21 how do you get the kernel loading? 23:26:35 what do you mean? 23:27:56 --- join: userx (connected@adsl-83-191-163.sav.bellsouth.net) joined #osdev 23:28:58 --- part: userx left #osdev 23:31:25 geist : just asking how the bootprocess works on the dreamcast 23:31:35 oh 23:31:49 well, the neato thing about the DC is it requires no hardware mods 23:31:53 it'll boot cdroms directly 23:31:57 so it's pretty easy 23:32:12 ohh 23:32:32 and how does it perform? 23:32:36 did you do any tests? 23:34:27 it's okay 23:34:32 the dreamcast has a 200Mhz sh-4 23:34:39 it's relatively quick 23:34:47 pretty simple risc machine 23:35:03 so it acts pretty much like all the other simple risc machines 23:35:11 it has a pretty kick ass fpu though 23:35:18 totally designed for vector stuff (like 3d games) 23:37:30 cool :) 23:40:02 g'nite, and thanks for the help 23:40:17 --- quit: malenfant (""sleep..."") 23:59:59 --- log: ended osdev/02.09.04