channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=2&d=6
12:49:11 <nyc`> I may be better off getting into C ASAP so I don't waste time on asm for unprivileged architectural features. A digression into how li is a pseudoinstruction and going over how to set each 16-bit slice of a 64-bit register from immediates was not the best use of my time, particularly when I hadn't actually found the serial ports.
01:04:35 <nyc`> It is kind of cool to get an instruction-by-instruction breakdown of how things really work on a few different arches. Kind of like how TAOCP does things in MMIX except it's multiple real architectures.
01:18:38 <jjuran> Bro, do you even shift? :-)
02:08:58 * geist yawns
02:50:16 <nyc> Ugh, it's pretty painful to figure out what's going wrong with my MIPS thing. Maybe I should context switch to ARM.
03:16:17 <kingoffrance> well, its incredibly ugly, but if you are just trying to get outside communication, couldnt you just patch qemu so read/write to address forwards to host? you probly dont want to recompile qemu, doubly so for windows
03:16:44 <kingoffrance> or is it more involved than that :)
03:17:20 <klys> and that would be called htif, which is deprecated because it breaks the rules of emulation
03:19:14 <nyc> kingoffrance: bochs has a magic IO port like that. It's basically just a serial port where you don't have to check the line status register or whatever.
03:19:55 <geist> generally if it's a pc you can prretty safely just start blatting stuff out of com1
03:20:02 <geist> without actually initializing it (on qemu that is)
03:20:07 <kingoffrance> i had a apollo os inside mame that didnt support serial ports AFAIK...i just added a raw disk, wrote tar file (for cross compiler), "decoded" on host side (padding) ... ghetto, but easieer than messing with networking
03:20:41 <geist> yah we do something like that for some fuchsia virtualized testing
03:20:57 <geist> just blat out the results of the tests to a virtualized disk so you can easily read it afterwards
03:21:06 <kingoffrance> i did the same for tru64 because emulating alpha is slow on my old laptop
03:21:31 <nyc> geist: I'm probably getting the magic address wrong for the model with PC ISA emulation.
03:21:46 * geist nods
03:22:16 <geist> nyc: usually i start adding printfs to qemu to see what its doing if i get completely confused
03:22:32 <nyc> I may also be neglecting to add in the virtual address.
03:22:44 <nyc> Or virtual offset or whatever.
03:23:04 <geist> right, so go verify that, which bifircates the problem
03:23:19 <geist> as in are you actually doing what you're think you're doing or did you get it wrong in the first place
03:25:37 <geist> or the other way of looking at it is step 1: verify that you're doing what you're think you're doing
03:25:50 <geist> then step 2 would be is what you think you're doing correct
03:26:50 <nyc> My first thought was trying to get gdb going on the asm thingie I have going.
03:27:05 <geist> yes, but you're on qemu and you have a ton of capability to debug what you're doing
03:27:15 <geist> this sort of thing is fairly trivial to debug
03:27:51 <geist> you can stop it and inspect, run it in tracing mode, or even go in and add printfs inside qemu where you think your mmio access should come through
03:27:56 <geist> it's an extremely powerful tool
03:32:19 <doug16k> yay! got initrd fs done and moved ide, ahci, nvme, rtl8139, 8042 drivers, gpt, mbr partition recognizers, fat32, iso9660 filesystems are all in dynamically loaded kernel modules
03:33:00 <doug16k> still need to move XHCI USB and the USB storage and HID class drivers out to modules though
03:33:11 <klys> doug16k, version number?
03:33:43 <klange> doug16k: gib release image plz
03:51:11 <doug16k> klange, once I get the GUI going a bit more and have terminal I/O working, I'll put one together asap
03:51:44 <nyc> Adding in the start of kseg1 didn't help. I'll have to brew up a qemu ready to debug tomorrow.
03:51:57 <nyc> doug16k: What did you get all this going in?
03:52:08 <doug16k> language you mean?
03:52:18 <nyc> doug16k: project
03:52:35 <doug16k> https://github.com/doug65536/dgos
03:52:42 <klange> call when you got a Quake port, that's all that really matters in life ;)
03:52:52 <doug16k> klange, it's coming :D
04:01:29 <dasabhi> hey guys has any one here previously published on OSDI under usenix?
04:05:53 <nyc> I only published at the Ottawa Linux Symposium and Kernel Summit conference proceedings.
04:06:54 <klys> operating systems design and implementation.
04:08:48 <dasabhi> i am wondering if they frown on independent publications
04:09:02 <dasabhi> or papers coming from smaller universities
04:10:22 <nyc> It's often difficult to get things through to the editorial board without a "big sponsor" so to speak.
04:12:39 <klange> A big sponsor like Waterloo?
04:12:52 <klange> Most of that stuff goes through the university anyway.
04:14:17 <nyc> Waterloo probably could do it.
04:14:39 <dasabhi> yeah but if you are not a waterloo student
04:16:19 <klange> You just stealing their wifi?
04:16:36 <dasabhi> how do you guys know i am coming from waterloo lmao
04:16:45 <dasabhi> i am a student right now
04:16:56 <dasabhi> but i am goin to a smaller university in the fall
04:17:05 <dasabhi> going*
04:17:24 <doug16k> your reverse DNS is waterloo.ca
04:17:37 <doug16k> uwaterloo.ca*
04:29:47 <nyc> I don't have a big sponsor, so I don't really see any potential for publication.
04:30:03 <nyc> When you do have them, they tell you what and if you can publish.
04:30:19 <nyc> So it's a no-win situation.
04:34:14 <dasabhi> interesting
04:34:38 <dasabhi> well i dont think waterloo really cares what you publish as long as its credible
04:35:19 <dasabhi> nyc: but are you saying that you always needs a sponsor to back you up for usenix publications?
04:35:42 <nyc> https://www.usenix.org/conference/osdi18/technical-sessions <-- zero papers from outside of big unis and companies.
04:36:15 <nyc> The pattern will repeat if you look around at more conferences.
04:37:25 <nyc> It's taken as a sort of review process. If you weren't good enough to get a big sponsor, or your stuff wasn't good enough to get a big sponsor, then you or your stuff are not good enough for consideration for the conference, or so the logic of it goes.
04:39:00 <dasabhi> yeah thats a bunch of bullshit
04:39:06 <dasabhi> but i guess thats how it is
04:39:34 <dasabhi> i have noticed some papers come from open source foundations
04:39:36 <nyc> I've gotten things even while I was at companies where they were not backing me up for publication etc.
04:39:55 <dasabhi> i am guessing you werent on the research teams
04:40:05 <klange> Go back to school so I can publish my "How to Waste Your Life Building an Operating System That Does Nothing New and No One Cares About"
04:40:09 <nyc> No, I was not.
04:40:52 <kingoffrance> im neither student, nor ever published, nor likely ever will, but i like djbs suggestions https://cr.yp.to/writing.html e.g. "One of the easiest ways to increase the time that readers are forced to spend on your paper is to bury some of the main points of your paper in a section near the end.'
04:41:04 <kingoffrance> i like devils guides, what can i say
04:45:50 <kingoffrance> i also suggest something i have seen a few times, mention a "prototype" you built, but never provide a url. that is very helpful too
04:47:51 <nyc`> I actually have a couple of novel ideas.
04:51:15 <dasabhi> well i wonder if you get get one of the bsd foundations or any open source org to backup your idea
04:51:26 <dasabhi> or "sponsor" it
04:52:38 <kingoffrance> videos are cool too, because when the link inevitably dies, noone will want to see it anyways, so problem solved. the main thing is to avoid the idea that science is about indepedent reproduceable results as much as possible...just tease the audience with things they wish they could see
04:59:27 <nyc`> I'm pretty sure that if I ever get any sponsorship, it'll only be after a relatively polished product is waiting for them on a silver platter.
05:01:45 <nyc`> I might as well not bother lifting my nose from the grindstone until it can run TPC-C et al.
05:06:10 <nyc`> I suppose I'll have to patch up postgres to get benchmark numbers because neither DB2 nor Oracle will port without a lot of buzz.
05:22:00 <kingoffrance> a good example of proper angelic terminology is calling things "object" e.g. in C, as "the file/stream object" ...this will make sure beginner readers have to spend more time discerning how your "objects" differ from other object-oriented "objects". == more time reading your publications
05:22:50 <nyc`> Angelic terminology? What on Earth?
05:23:30 <kingoffrance> sarcasm nyc. waterloo was asking help publishing papers
05:23:37 <ybyourmom> nyc`: Nice pun
05:25:03 <nyc`> I suspect obfuscation would be met with resistance.
05:29:33 <nyc`> Then again, my papers were very tough to get through and made it into OLS & KS no problem.
05:29:53 <klange> I should have published something in college...
05:29:59 <klange> I feel like I missed my opportunity.
05:30:30 <geist> i shoulda partied more in college
05:30:53 <klange> I have a good party story.
05:31:07 <nyc`> I contributed a lemma to a paper on repunits in '94.
05:31:28 <ybyourmom> Lemme here being the formal methods stuff?
05:31:41 <ybyourmom> I should probably get my name on a paper before leaving this job
05:32:06 <nyc`> It was a math paper.
05:32:25 <ybyourmom> Ah, then probably not formal methods
05:34:48 <nyc`> Repunits are numbers that are all 1's in the base they're a repunit relative to.
05:42:31 <nyc`> Integer numbers
05:45:10 <klange> "recreational mathematics"
05:48:43 <nyc`> I wasn't the main impetus behind the paper. The actual author asked me a question and I answered it.
05:51:31 <nyc`> I don't even remember any details about what I proved, just that he routinely said that he was crediting me in his paper when I knew him.
06:08:29 <nyc`> It wasn't by dint of verbiage that my conference papers were difficult to read. The concept was difficult.
06:41:58 <nyc`> It would probably actually be safe to openly describe my grandest idea because it's too invasive to retrofit and would take a lot of pain to write a whole kernel around.
06:42:27 <klys> are you sleepy
06:42:30 <klange> reveal all your secrets
06:43:08 <klys> covet to prophesy
06:52:20 <ybyourmom> nyc`: I'm all ears
06:57:17 <klys> wb
06:57:33 <ashkitten> ayo
06:57:54 <ashkitten> guess i didn't save my weechat config, i think my server auto rebooted overnight
06:58:04 <klys> :.)
06:58:21 <ashkitten> it's ok i just lost a bit of autojoin configuration
06:59:57 <ashkitten> i forgot weechat doesn't save configs unless you tell it to
07:01:23 <ashkitten> what time is it ugh
07:01:32 <ashkitten> 02:00 wtf
07:01:45 <ashkitten> my sleep schedule is not a thing that exists
07:06:47 <nyc`> Well, like all algorithms etc., it's best described in code. Seriously, though, it would be a massive project.
07:07:29 <nyc`> And I am sleepy.
07:07:51 <ashkitten> should sleep
07:11:25 <nyc`> It's like saying to write an algorithm for unified register allocation and instruction scheduling using a multigraph to represent conflicts and dependencies.
07:13:49 <nyc`> I'm sure someone could write a compiler using that idea, but just saying that doesn't help you much.
07:15:15 <ashkitten> are we talking about a compiler that outputs concurrent code automatically again?
07:16:58 <ashkitten> also, don't x86 chips already do this, what with instruction reordering and speculative execution?
07:17:20 <ashkitten> not that it wouldn't be better to do it during the compile stage
07:20:37 <FireFly> morning
07:20:47 <ashkitten> hi
07:22:38 <immibis> note that the chip knows things the compiler doesn't, e.g. things can be scheduled based on the actual values in registers
07:23:24 <immibis> dividing by 1 might be really fast, whereas statically scheduled code would have to wait for the worst case division
07:54:53 <Ameisen> evidently, certain -mllvm arguments passed to clang cause it to not properly assemble assembly
07:55:10 <Ameisen> that is, clang -c test.S -o test.o will... 'succeed'
07:55:15 <Ameisen> but it will just emit... the assembly itself.
07:58:12 <Ameisen> was throwing me off that this build kept complaining about a missing '.text' symbol.
07:58:23 <Ameisen> the fact that ld was actually able to parse it enough to derive that is impressive, though
07:58:56 <Ameisen> Are there any standard 'compressed' object file formats or archive formats for object files that gcc/clang/ld would understand?
08:10:25 <doug16k> there is compressed debug info
08:11:59 <doug16k> --compress-debug-sections=zlib
08:16:01 <Ameisen> I mean, just compressing the entire object file.
08:16:05 <Ameisen> but in a way that it can still be used
08:17:25 <doug16k> g++ -o thing <(gunzip < obj1.o.gz) <(gunzip < obj2.o.gz)
08:17:27 <doug16k> :D
08:20:55 <doug16k> doubt that would work though, it probably needs to be able to seek the obj files
08:21:12 <doug16k> seeking and compression are not on friendly terms usually
08:21:42 <doug16k> Ameisen, why do you want compressed object files? I'm curious
08:36:12 <knebulae> @nyc: and now you understand why someone might have the motivation to go into a random forum and drop earth shattering knowledge; kind of like the 4chan guy and the mathematical discovery (fastest way to compute some special type of number?)
08:36:51 <knebulae> If people won't listen, a tidbit here and there that's true will eventually get someone's attention.
08:37:28 <kingoffrance> doug16k is right, (g)cc wants to seek :) https://www.freebsd.org/cgi/man.cgi?query=mount_portal&apropos=0&sektion=0&manpath=NetBSD+1.5&arch=default&format=html
08:38:02 <kingoffrance> portalfs == ancient, but shell/program independent :)
09:03:54 <kingoffrance> you can of course just write a wrapper script around cc, that when it sees a foo.o.gz file, it decompresses to /tmp/somewhere, does the compile, and traps to remove tmp file on exit. for a full toolchain, would require writing a few wrapper scripts.
09:04:03 <kingoffrance> "sees" == on command line
09:04:37 <kingoffrance> and then use ccache pointing to wrapper script, it probably wont even notice
09:11:11 <Ameisen> doug16k - reduce file sizes.
09:11:27 <Ameisen> kingoffrance - you can _technically_ implement seeking with zlib.
09:13:57 <zhiayang> i'm very confused why libstdc++ suddenly does not want to build
09:14:00 <zhiayang> i've done it before
09:14:32 <Ameisen> the build system sometimes gets moody
09:15:18 <zhiayang> according to myself one month ago, i "fixed" it by using less -js on make
10:04:09 <kingoffrance> also with freopen() and similar, e.g. my "stream" library i will have a "make_seekable" backend, that could be stacked e.g. on top of stdin or whatever. it will just 'cache' basically, giving the illusion stdin is "seekable"
10:05:43 <kingoffrance> whoops, s/freopen()/funopen()/ of course
10:06:31 <kingoffrance> djgpp has something similar to funopen(), linux has something similar
10:10:24 <kingoffrance> it should be possible to do some LD_PRELOAD trickery to reroute open() etc. to fool gcc or whatever. if you saw a gz filename (which gcc or whatever would normally never get) make it use your custom "seekable" stream, perhaps using funopen()/etc. it would be a bit of work to implement all "stream" functions, and if not your custom thing, pass to the "normal" ones. possible though, i believe
10:10:36 <kingoffrance> wayyyy too much work i know, but totally possible
10:29:58 <ashkitten> kingoffrance: i'd honestly like to see something that does this for arbitrary programs that don't accept gzipped content
10:33:43 <ashkitten> tbqh you could with a program that takes a gzipped file and returns a special stream mapped to the filesystem like that
10:34:22 <ashkitten> or even a more generic program that takes normal streams and wraps them making them seekable
10:35:07 <ashkitten> not sure how exactly the last thing would work, or if it's possible without collecting the whole thing in a tempfile
10:35:19 <ashkitten> but yeah
10:40:27 <zhiayang> great
10:40:38 <zhiayang> the solution is to throw one enable_dlopen=no at the bottom of libstdc++v3/configure
10:40:58 <zhiayang> how tf does gcc even "check" for it? i've gone as far as *defining* stub functions for them
10:51:23 <Ameisen> autoconf.
10:51:31 <zhiayang> right, but how
10:51:41 <Ameisen> it tries to build a program that uses it
10:51:46 <zhiayang> like i know for functions and stuff they make a stub program and build it
10:51:54 <zhiayang> ya exactly, so what's going on that it's not building
10:52:03 <zhiayang> surely they don't go as far as to check the return values
10:52:12 <Ameisen> in some cases, they do.
10:52:16 <zhiayang> (besides, it's totally standards compliant to just return null on failure)
10:52:24 <Ameisen> the stub program was likely building/operating differently in the autoconf context than during the build
10:52:30 <Ameisen> that's something I've been dealing with a lot.
10:52:35 <zhiayang> sigh
10:52:37 <Ameisen> though USUALLY, it's the other way around
10:52:50 <Ameisen> the stub fails where the main build would work fine due to some weird ordering of arguments
10:53:16 <zhiayang> the problem is, i don't even see the stub program's contents in config.log
10:53:19 <zhiayang> so i don't know what i'm missing
10:54:11 <Ameisen> I should point out that I absolutely hate autoconf
10:54:16 <zhiayang> oh yes
10:54:32 <zhiayang> the scum of the earth
10:54:56 <Ameisen> for dlopen, they're looking for, well, dlopen
10:55:12 <zhiayang> the issue is, it doesn't say "checking for dlopen... no"
10:55:16 <Ameisen> for linux, a tleast, dlfcn.h and libdl.a
10:55:24 <Ameisen> might be in a different configure.
10:55:34 <zhiayang> it's "checking for shl_load... link tests are not allowed after GCC_NO_EXECUTABLES"
10:55:36 <Ameisen> gcc is set up as a bunch of smaller projects
10:55:42 <Ameisen> but I think they share state files
10:56:01 <zhiayang> hm, is it necessary to have a libdl?
10:56:12 <Ameisen> that's presumably where they'd expect to find dlopen.
10:56:23 <zhiayang> but dlopen is supposed to be in libc, no?
10:56:54 <Ameisen> libdl is part of glibc
10:56:59 <zhiayang> jeez
10:57:07 <zhiayang> let me have a try
10:57:15 <Ameisen> I don't recall how musl handles it
10:57:26 <Ameisen> I'm guessing musl just packs it all into libc.a
10:57:50 <Ameisen> sleep time
10:57:53 <Ameisen> it's 5 AM
11:03:36 <klange> Mine is built-in to the dynamic loader itself, but those musl peeps love their static linking.
11:03:54 <klange> There are fake shadow methods in my libc...
11:06:49 <mobile_c> klange: u make ur own dynamic loader? 0.0
11:07:19 <zhiayang> we are in #osdev, making your own ___ isn't exactly uncommon
11:07:32 <klange> Everything in ToaruOS is original to the project.
11:07:54 <klange> From the bootloader to the kernel to the drivers to the libc to the ld.so to all of the apps and libraries.
11:08:03 <klange> The only third-party stuff is whatever libgcc crap leaks in.
11:08:09 <mobile_c> so ur linker is compatible with gnu libc and musl libc? 0.0
11:08:16 <klange> What do you mean?
11:08:30 <klange> It implements the necessary functions and can load ELF shared libraries.
11:08:37 <klange> It is not meant to run on a glibc or musl environment.
11:08:50 <mobile_c> like it can load applications compiled with glibc/musl
11:08:54 <klange> No?
11:08:58 <mobile_c> rip
11:09:01 <klange> musl/glibc have not been ported to my OS
11:09:05 <klange> so that's illogical
11:09:15 <klange> I'm sure it could load them just fine... against those libraries.
11:09:30 <mobile_c> i should try to finish my dynamic loader
11:09:38 <mobile_c> havnt worked on it in ages
11:09:40 <klange> I'm not sure you understand what a dynamic linker is supposed to do if this is a question you are asking.
11:10:21 <kingoffrance> well, that is one reason i dont use autoconf etc. it is probably more bad maintainers, but on the occasion they do check function return values instead of just "does test program compile" ... that totally breaks when cross-compiling. theoretically they could add an env var "launch program on target" but ...
11:10:27 <mobile_c> mine aims to be able to succesfully load both musl and glibc compiled applications
11:10:55 <kingoffrance> "more bad maintainers" meaning not inherent to autoconf, but some ppl write it with too many assumptions
11:11:55 <zhiayang> well it's not libdl that's the problem
11:11:58 <klange> I would be unable to test such a thing because I do not have a port of glibc to load in the first place, and glibc is a giant trash heap to port.
11:11:59 <zhiayang> still fails
11:12:22 <zhiayang> at this point i'm wondering if i should even bother to figure out what's going on
11:12:25 <klange> I had newlib previously, I replaced it. ToaruOS is, in its entirety, built from scratch.
11:15:01 <klange> mobile_c: There is not really much different about things built against musl or glibc or any other libc.
11:15:15 <klange> There may be advanced features glibc uses related to cosntructors or thread local storage.
11:15:38 <klange> But generally when you've built a dynamically linked binary it's just a bunch of relocations...
11:15:50 <klange> I have implemented all the ones I've found in the wild so far.
11:16:41 <mobile_c> yes but you also need to keep track of symbols so the same symbol does not get processed twice
11:17:15 <klange> Yes?
11:17:40 <klange> That's not really important to comparing musl/glibc/otherlibcs
11:19:02 <mobile_c> true
11:19:20 <klange> My dynamic linker works so far as it can support my dynamically-linked userspace, with a dynamically-linked libc and libraries, can support runtime linking of additional libraries which I use in my window decorator, and Python can load C modules.
11:20:56 <mobile_c> cool
11:21:37 <klange> (And my libc also supports all of that; Python was fun to get working again after I abandoned newlib)
11:21:42 <klange> (gcc was *super crazy*)
11:26:37 <zhiayang> (mfw it takes longer to extract gcc than to build it)
11:26:52 <zhiayang> wsl io is really trash
11:28:09 <klange> yeah
11:34:36 <ashkitten> would be neat to look into actually writing an os in rust
11:35:22 <klange> many have walked this path before you
11:35:25 <rain1> check phil-ops blog
11:36:26 <kingoffrance> ashkitten: for netbsd i would say http://mirror.larbob.org/NetBSD/NetBSD-release-8/src/sbin/mount_portal/pt_filter.c the popen() line is the magic spot to "wrap" and make it "seekable" (set a limit on bytes to cache)
11:36:56 <ashkitten> klange: yeah i'm definitely not the first, but i know next to nothing about this stuff so
11:38:12 <ashkitten> kingoffrance: so it'd be seekable, but only to a certain extent
11:38:22 <ashkitten> interesting
11:38:38 <ashkitten> ugh i need to look into netbsd
11:38:39 <zhiayang> the phil os blog kinda
11:38:43 <zhiayang> isn't that great
11:38:46 <zhiayang> tbh
11:38:52 <zhiayang> like it focuses on writing rust, not writing an o
11:38:53 <zhiayang> *os
11:39:13 <mobile_c> ok time to see how my linker preforms
11:39:23 <ashkitten> might try running netbsd on my server when i upgrade it
11:39:26 <mobile_c> loader*
11:39:41 <mobile_c> 11 months since i last touched it o.o
11:39:58 <Mutabah> zhiayang: It looks like most other OS tutorials, except for the language
11:42:41 <zhiayang> hm, that wasn't really my impression
11:42:49 <zhiayang> but regardless it's good to have a coherent tutorial in one place
11:43:16 <mobile_c> i hope it doesnt eat all my ram ;-;
11:52:05 <mobile_c> and i get library[0].NEEDED[0] = NULL
12:00:45 <mobile_c> so this may be why
12:00:47 <mobile_c> libc.so.6 => not found (parent: ./hello.so)
12:12:11 <kingoffrance> ashkitten: actually, for just gzip/bzip whatever, you could make it fully seekable. for stdin set a limit to "cache" though since you dont know how big it is /cant "reread" it. for gzip file you can always "reread" so full seek is fine
12:12:37 <ashkitten> yeah
12:58:18 <mobile_c> ughhh i feel like my loader is overcomplicated
12:58:36 <mobile_c> is it normal for a loader to be 4k lines?
01:00:58 <Lowl3v3l> mobile_c: depends entirely on what it does load and what else it does.
01:02:12 <mobile_c> it loads a glibc application
01:04:27 <Lowl3v3l> depending on what part of which execuable formats it understands i'd say its not that long
01:18:05 <mobile_c> welp
01:19:07 <mobile_c> assuming i can correctly read a shared object and correctly relocate the symbols... what would i need to do in order to load a glibc application
01:26:08 <mobile_c> or not...
01:26:39 <mobile_c> ok my loader is confusing
02:01:39 <mobile_c> ok so i cannot readelf two different libraries in the same instance
06:19:27 <w1d3m0d3> do intel hd graphics (specifically 4400) implement VESA VBE and would Windows XP be able to take advantage of those even without additional drivers
06:21:36 <fluffy0> i would assume it does, but i don't know
06:21:42 <geist> most likely, yes
06:21:57 <geist> as far as XP taking advantage of it, who knows
06:22:14 <geist> AFAIK there was never a VESA fallback driver for windows. it would usually fall back to plain VGA modes
06:22:36 <geist> but that may not be true. i think it maybe could fallback to 1024x768, which i guess is not plain VGA
06:22:44 <geist> could be using VESA for that
06:22:54 <geist> whatever it falls back to, it's usually unaccellerated though
06:27:55 <ashkitten> fluffy0: are you the fluffy i know from kaleidoscope?
06:28:04 <w1d3m0d3> uhh im pretty sure 10 used VBE in my VMs as a fallback
06:28:23 <fluffy0> ashkitten: nah, i'm fluffy with a zero :)
06:28:40 <ashkitten> so, no then
06:28:42 <ashkitten> okay
06:29:56 <geist> hi fluffy with a zero
06:30:09 <geist> w1d3m0d3: okay, then that's probably true
06:30:15 <fluffy0> hi there geist
06:31:07 <geist> hmm, for some reason my VM host box went down sometime yesterday
06:31:15 <geist> good old reset button brought it back
06:31:38 <ashkitten> im trying to work on setting up irc from my laptop but if i touch it wrong it goes into hibernate
06:31:47 <ashkitten> love broken laptops
07:01:46 <doug16k> w1d3m0d3, my acer laptop with intel graphics has excellent VBE support
07:21:45 <mobile_c> why is this so difficult ;-;
07:23:05 <mobile_c> Lowl3v3l: halp meh ;-;
07:44:22 <CrystalMath> <mobile_c> why is this so difficult ;-; <- osdev in a nutshell
07:45:03 <CrystalMath> though idk, i never cried while working on the kernel
07:45:14 <CrystalMath> i did cry while writing a game for the 286 in assembly
07:49:40 <w1d3m0d3> doug16k: awesome, I hope I can expect Windows XP rendering fine even with CPU-based graphics on XP
09:43:13 <mrvn> "I want you to find Polly." (Polly, the school mascot)
09:50:21 <ryoshu> should x86 ud2 instruction raise SIGILL with si_code==ILL_ILLOPN or si_code==ILL_PRVOPC ?
09:50:51 <mrvn> yes, maybe, maybe
09:51:37 <mrvn> ILL_PRVOPC would indicate user tried to do something only kernel may do. So I would expect the former. Have you tried?
09:51:59 <ryoshu> Linux returns ILL_ILLOPN, NetBSD and FreeBSD ILL_PRVOPC
09:52:51 <ryoshu> but oprand.. does ud2 have an operand at all?
09:56:25 <w1d3m0d3> if I was to use gcc -M would I need to regen the makefile?
09:59:39 <mrvn> w1d3m0d3: you output it into foo.d and include *.d
10:00:19 <mrvn> I recommend -MD -MP
10:00:37 <kingoffrance> re: few hours ago, yes, from my experience, old windows (xp and older lets say) 16 color 640x480 if no video driver. if there is a vesa driver, it sure doesnt try very hard/probe. possibly there is 3rd party though (e.g. scitech display doctor or similar may have made "windows" drivers)
10:00:40 <w1d3m0d3> .d?
10:01:55 <mrvn> d as in Dependency
10:01:58 <mrvn> include $(wildcard *.d)
10:02:21 <mrvn> to include all generated *.d files. Avoids an error if there aren't any
10:02:24 <w1d3m0d3> yeah I guessed so but won't the file be something like `: Dep1 Dep2 ...`
10:02:36 <mrvn> w1d3m0d3: yes
10:02:58 <mrvn> % cat kernel/allocator.o.d
10:02:58 <mrvn> allocator.o: allocator.cc /home/mrvn/src/moose/include/stddef.h \ /home/mrvn/src/moose/include/memory.h \
10:03:01 <mrvn> ...
10:04:07 <w1d3m0d3> okay the output is different than I expected
10:04:43 <w1d3m0d3> can the deps be declared before the target recipe is defined
10:04:57 <olsner> I usually use $(OBJECT:.o=.d) to get just the dep files I want, and -include to ignore missing ones (-include also changes how make reacts to changes to the dependency files, since "include" adds an implicit dependency from Makefile to the dep file)
10:05:03 <w1d3m0d3> also what's the point of those targets including system header files?
10:05:10 <mrvn> w1d3m0d3: before, after, who cares
10:05:22 <w1d3m0d3> oh okay
10:05:27 <w1d3m0d3> I thought they had to be joined together
10:05:42 <mrvn> w1d3m0d3: so that when you update your libc you recompile. Use the -Mx option you like.
10:06:13 <w1d3m0d3> yes I know that, but -MP makes it generate for example `/usr/include/stddef.h:` leaving them empty
10:06:27 <mrvn> w1d3m0d3: usualy you have a pattern rule for %.o: %.c and the depends for file.o: file.c
10:06:34 <olsner> iirc the documentation for -MP explains why you'd want that
10:06:57 <mrvn> w1d3m0d3: the docs explain it. Avoid errors when you delete a file
10:07:01 <w1d3m0d3> ah it works around the errors when you remove files
10:07:03 <w1d3m0d3> yea
10:08:12 <w1d3m0d3> this won't cause problems before the .d files are generated? (is that what the - in -include means)
10:08:25 <nyc`> -ffreestanding is probably best for the kernel.
10:08:50 <mrvn> - means ignore the error, $(wildcard *.d) evaluates to empty if none are present and avoids the error altogether
10:08:51 <nyc`> Or whatever that option's name is.
10:09:06 <mrvn> w1d3m0d3: and use a cross compiler
10:09:13 <w1d3m0d3> yeah yeah I know
10:09:22 <w1d3m0d3> I did that test with system GCC just to see what it would output
10:09:38 <mrvn> you obviously screwed up the compiler and/or compile flags. Otherwise `/usr/include/stddef.h:` would not be there
10:09:44 <mrvn> ahh
10:12:38 <kingoffrance> nyc`: now that you're awake, you can better describe your grand ideas :)
10:12:55 <w1d3m0d3> 1) take down the white house
10:12:56 <kingoffrance> hint hint nudge nudge
10:13:04 <mrvn> my ideas are far garnder while I'm asleep
10:13:23 <nyc`> I don't think you need a cross compiler until you've got your own userspace. I thought -ffreestanding or similar existed to deal with kernels.
10:13:43 <mrvn> nyc`: you only need a cross compiler UNTIL you've got your own userspace
10:14:17 <mrvn> nyc`: a cross compiler prevents you using the wrong flags. Forgetting -ffreestanding is only one of them.
10:15:08 <nyc`> Hopefully clang or some such is better about these things.
10:15:14 <kingoffrance> well, c "freestanding" is probably roughly "kernel space" and "hosted" is roughly "user" but from C point of view, it is all just implementation-defined. in all likelihood yes, but C doesnt use "kernel mode" and "user mode" because it doesnt define a "kernel" :)
10:15:16 <mrvn> nyc`: no
10:15:49 <w1d3m0d3> I can confidently tell you you can get away without a cross compiler without userspace but it's neater to have one
10:16:03 <mrvn> nyc`: the options are the same for gcc and clang and if you mess them up you get system files into your kernel.
10:16:23 <mrvn> nyc`: only clang is worse because it doesn't have a freestanding cross compiler. Only one full one for everything.
10:17:00 <nyc`> Wow, that's discouraging.
10:17:21 <w1d3m0d3> I should get back to osdev soon
10:17:51 <mrvn> nyc`: just don't screw up your options and you're fine. You can always tryy a gcc cross compiler.
10:19:10 <nyc`> mrvn: I mean in the sense that preexisting compilers are so wrongheaded.
10:20:10 <mrvn> nyc`: nothing wrong about them. They do what you tell them to.
10:27:09 <nyc`> I'm a long way from grinding out my own HolyC.
10:29:38 <haxmoLLC> omg tell me about it, can one of them just enable all warnings by default already, call it C specification mode.
10:29:58 <mrvn> haxmoLLC: you mean -pedantic?
10:30:06 <haxmoLLC> and then?
10:30:14 <mrvn> then it honors the C specs
10:30:26 <haxmoLLC> a lot of them
10:30:31 <mrvn> all of them
10:30:35 <haxmoLLC> heh
10:30:41 <mrvn> excluding compiler bugs
10:31:02 <mrvn> just too bad warnings aren't part of the C specs
10:31:04 <kingoffrance> you guys bringing holyc up, i had to revisisit to see why i avoided it. hardcoded u16 u32 u64 etc, c++ "classes", and, CaseIDontLike. anyone that dedicated i cant say doesnt know what hes doing, but i would choose total opposite on all those
10:31:23 <kingoffrance> props to him, but i stay far away
10:31:38 <mrvn> WTF? u16 u32 u64 are obsoleted by stdint.h
10:31:51 <nyc`> I just walked past a store blasting The Right Stuff by the New Kids on the Block as I'm saying I'm not ready to have my own HolyC.
10:35:57 <nyc`> C covers up too much about the stack, which is awkward when you're trying to use interrupt model programming.
10:36:39 <mrvn> nyc`: you can't use C for interrupts or task switching. Even the gcc extension is only good for part of it
10:37:09 <mrvn> but seriously. That's like 100 line asm against 10000000 lines C in your kernek
10:38:23 <mrvn> nyc`: by the way, the stack stuff is part of the calling conventions you use.
10:39:20 <nyc`> kingoffrance: As far as grand ideas go, priority of publication matters.
10:44:41 <nyc`> mrvn: I think you're thinking of something else. Interrupt model programming wants continuation passing style etc. C variations of it use hand-rolled callback spines like bcrl's worktodo from RHAS2.1.
10:45:10 <mrvn> nyc`: yes, then I'm thinking about something else. Try ocaml.
10:47:17 <kingoffrance> mrvn: i should say I16 I32 I64 he just hardcoded those as basic types AFAIK
10:47:52 <kingoffrance> "made up his own" in other words
10:48:08 <mrvn> did he use long?
10:50:02 <jmp9> Hello everyone. I'm planning to do some paging, but I need know how much there is available RAM. How I can do this after booting from GRUB?
10:51:41 <haxmoLLC> http://www.google.com/search?q=osdev+detect+ram
10:51:48 <nyc> mrvn: The kernel needs manual memory allocation.
10:53:39 <kingoffrance> mrvn: i think they all get "upcast" to I64 IIRC; he is 64-bit x86 only
10:54:01 <jmp9> Yes, I know
10:54:07 <jmp9> Basically i'l allocate 4K pages with paging
10:54:28 <jmp9> and then implement some small bitmap allocator to allocate memory smaller than 4K
10:55:24 <nyc> jmp9: Page allocators can work a few different ways. Small allocations are usually things like slab allocators.
10:55:36 <jmp9> yes this shit is complicated
10:56:16 <jmp9> for my needs bitmap allocator will be enough
10:56:37 <kingoffrance> many would argue some of those are outdated, but holyc clearly broke #10. https://www.lysator.liu.se/c/ten-commandments.html
10:56:44 <kingoffrance> just as prophesized
11:05:16 <nyc> jmp9: Like a buddy allocator?
11:11:48 <nyc> jmp9: Buddy allocators still need lists.
11:50:21 <jmp9> Okay I read GRUB multiboot header specification
11:50:22 <jmp9> and
11:50:23 <jmp9> -4 | size |
11:50:27 <jmp9> what this means
11:50:42 <jmp9> that if we have pointer to structure, then i need substract 4 to get pointer to size?
11:50:58 <jmp9> because in osdev example size are just first value in entire structure
11:51:12 <jmp9> and multiboot specification that it below structure
11:52:56 <haxmoLLC> maybe, if you're using qemu you can set ram with -m option, `qemu -m 64M` for example
11:53:57 <jmp9> I found bug
11:54:02 <haxmoLLC> and read arbitrary memory addresses with "x 0x31337357"
11:54:08 <haxmoLLC> in the qemu monitor console
11:54:19 <jmp9> i got null pointer in ebx
11:54:32 <Mutabah> jmp9: I believe that the sample code on the wiki subtracts 4 from the base address before starting
11:54:34 <jmp9> and working magic value in eax
11:54:59 <jmp9> multiboot_memory_map_t* mmap = mbt->mmap_addr;
11:55:13 <jmp9> this in the loop
11:55:13 <jmp9> mmap = (multiboot_memory_map_t*) ( (unsigned int)mmap + mmap->size + sizeof(mmap->size) );
11:55:24 <jmp9> typedef struct multiboot_memory_map { unsigned int size;
11:55:33 <jmp9> in structure we have size as first value
11:57:17 <jmp9> https://wiki.osdev.org/Detecting_Memory_(x86)