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=20&m=8&d=2
00:00:05 <doug16k> that offset is because that is the mbr
00:00:11 <doug16k> I don't boot my os from the mbr. that is totally wrong
00:00:59 <doug16k> mbr chooses the active partition, loads the first sector of _that partition_ to 0x7c00, sets up dl with drive number, and ds:bx with pointer to booted partition table entry, and jumps into that
00:01:19 <doug16k> because it needs to put it at 0x7c00, the mbr has to relocate itself to somewhere else
00:01:27 <doug16k> my mbr is linked at 0x600
00:01:50 <doug16k> that macro fudges the target to make it be the address it would be before relocating itself to 0x600
00:03:11 <clever> https://github.com/coreos/grub/blob/2.02-coreos/grub-core/boot/i386/pc/boot.S#L227-L238
00:03:12 <bslsk05> github.com: grub/boot.S at 2.02-coreos · coreos/grub · GitHub
00:03:21 <clever> looks like grub just assumes the linker is sane
00:03:33 <clever> while your not trusting the linker as much?
00:03:42 <doug16k> so it goes: 1) bios loads mbr, 2) mbr moves itself out of the way of 0x7c00, 3) loads 1st sector of partition to 0x7c00, 4) jmps into that, 5) that loads the rest of the bootloader from the partition, 5) actually run bootloader
00:04:36 <doug16k> clever, nothing to do with sanity. I have to move the mbr code out of the way to load the chainload boot code from the partition
00:04:36 <clever> that sounds roughly like the legacy MBR stubs, when the boot bit actually mattered
00:04:57 <clever> ahhh, so your linker doesnt know where the code lives, during the 2) stage
00:05:12 <doug16k> the bios loaded my mbr to 0x7c00, whether I like it or not
00:05:22 <clever> yeah
00:05:26 <doug16k> partition boot sectors expect to load at 0x7c00, whether I like it or not
00:05:27 <clever> but you told the linker its somewhere else
00:05:35 <doug16k> can't overwrite running code
00:06:00 <doug16k> it will return to lala land if I read into 0x7c00 while in a call from code in 0x7c00 range
00:06:00 <clever> the bug grub is dealing with, is differences in bios's `ljmp 0x7c0:0` vs `ljmp 0:0x7c00`
00:06:43 <doug16k> I don't care what that bloated piece of shit does
00:06:50 <stuff_is> ok I am setting ss to 0x07c0 and sp to some value after my stuff, 0x5400, which should be wrong when I change the segment again but hopefully not by much
00:06:55 <stuff_is> gonna restart and see what goes
00:07:01 <stuff_is> BRB
00:09:50 <stuff_is> is mov ax, 0 same length in actual machine code as mov ax, 0x07c0 ?
00:10:05 <doug16k> should be ya
00:10:09 <stuff_is> I wanna do it just to make sure it's the value in ss and not the length as you suggested
00:10:28 <stuff_is> ok setting ss to the same registers as other works on my real machine as well, even if I change the rest later in second stage but don't update ss
00:10:29 <doug16k> prefer xor ax,ax over mov ax,0 when you don't care about the flags
00:10:55 <doug16k> how many times do I have to repeat that you have to setup the stack pointer?
00:11:22 <stuff_is> I set it up? mov sp, 0x5400, mov bp, sp
00:11:32 <doug16k> that's half of the stack pointer
00:11:39 <stuff_is> half of it?
00:11:43 <clever> stack segment
00:11:46 <doug16k> stack pointer is ss:sp
00:11:54 <stuff_is> ss is 0x07c0 ?
00:12:06 <doug16k> dude who wrote this stuff on the wiki
00:12:30 <doug16k> you don't want pointers to be equal to the physical address?
00:12:39 <doug16k> you want some bullshit 0x7c00 invisibly added on?
00:12:48 <stuff_is> I alredy did all my calculations in python
00:13:13 <stuff_is> well I don't spend much time in that segment, I change my segments to 0x0800 as soon as I get to second stage bootloader
00:13:20 <stuff_is> since I load 4 Kb at that address
00:13:40 <stuff_is> it' a bit cumbersome but I only do what needs to be done until 32 bit mode
00:13:47 <doug16k> if your solution to "when I remove an instruction, it seems to work" is "ok, I'll remove it", then osdev will be difficult
00:14:09 <stuff_is> well I am not sure if removing an instruction fixes it, I haven't tested it
00:14:11 <doug16k> you need to set ss, whether you like it or not
00:14:23 <stuff_is> but seting ss from 0 to another value seems to fix it, on my laptop, it works on qemu either way
00:14:39 <stuff_is> I used to set it before too, to 0 tho...
00:14:48 <clever> doug16k, stuff_is: https://imgur.com/a/MeXPHuw
00:14:49 <bslsk05> imgur.com: Imgur: The magic of the Internet
00:14:56 <stuff_is> and sp to another value before 0x07c0, but now since ss is not 0, I ahve to set it up after all my stuff
00:15:16 <doug16k> make it equal to your ds, if you are sane
00:15:32 <doug16k> if you are a total nutjob, set them different. does that make it clear? :D
00:15:34 <stuff_is> I didn't want it to be equal to ds, cause I didn't want to accidentally write on my stack
00:15:36 <clever> when you pass a pointer to something on your stack to another function, insanity will begin
00:15:47 <stuff_is> I set it to 0, so I can set my stack before 0x7c00,
00:16:09 <clever> void foo () { struct bar baz; qux(&baz); }
00:16:14 <stuff_is> and as soon as I load my second stage I update my segments again, that way all my reasoning starts from 0 in the new segment
00:16:28 <clever> qux will now receive the address of something in the stack segment, but use the data segment when trying to reach it, have fun!
00:17:00 <doug16k> stuff_is, if your ds is 0x7c0 and your ss isn't, then your pointers are going to be screwy, because [bx] and [bp] point to two different things if ds != ss
00:17:07 <doug16k> even if bx and bp are the same value
00:17:31 <clever> and thats why i'm sticking to vpu/arm, where you just have plain and simple 32bit or 64bit addressing
00:17:31 <stuff_is> but that is before getting to protected mode, it's only for the bootloader
00:18:17 <stuff_is> well my print uses [fs:si] so I do absolute indexing anyway
00:18:32 <stuff_is> since fs is free to use, among with some other segment register
00:18:45 <doug16k> so you ask for help then argue that everything you do it right. good luck with that
00:19:48 <stuff_is> well IDK what is right, to me it just made sense to put ss at 0, but I changed it
00:20:06 <doug16k> and I'm one of the few people here that even give a rats ass about x86 bootloaders. most people here say use grubb
00:20:15 <stuff_is> I don't understand why intel made so many segment registers if the recommended way is for all of them to be equal
00:20:29 <stuff_is> makes no sense, you;d want to use different ones
00:21:00 <stuff_is> I read an article that grub is bad, and doesn't work if you want to install linux on some "hybrid" laptops, and refind works better
00:21:03 <doug16k> they didn't recommend that
00:21:13 <doug16k> that is so you don't add unnecessary confusion to the code
00:21:14 <stuff_is> or rather bad in a particular instance, on some hardware or w/e
00:21:25 <clever> stuff_is: i think the main reason to make them different, is when you are running low on address space
00:21:36 <stuff_is> well I still don't understand why setting ss to 0 broke it, and why it works in qemu :(
00:21:41 <clever> each self-contained chunk of the program could have its own segments
00:21:46 <doug16k> are you writing a 16 bit dos program that needs over 64KB? no? then don't use far pointers
00:21:52 <stuff_is> in my case I made them different cause I wanted the stack to be before the booloader
00:21:53 <clever> and dos can use the segments to skip doing relocation when loading a binary
00:22:09 <doug16k> I'm old enough to have wrote real mode code with far pointers for years. it sucks, bad
00:22:13 <stuff_is> well the VBE spec says that when they give you strings they can be anywhere , so I kinda have to use them
00:22:32 <stuff_is> I mean from my understanding they usually fill your structure and don't go outside, but the spec is unclear on that, they can give you a pointer to anywhere
00:23:02 <stuff_is> they give you both a segment and ptr to some strings like gpu name, and to the mode info pointer
00:23:32 <doug16k> yes you use those when you hae no choice
00:23:38 <stuff_is> at least on qemu, it seems to just fill the reserved area of the struct you pass, but IDK if that's true all the time
00:24:01 <doug16k> what you don't do is unnecessarily set it so non-stack accesses have 0 base, and stack accesses have 0x7c00 base
00:24:02 <stuff_is> the only reason I set it to 0, so I set it before my bootloader so I don't accidentally override it
00:24:06 <doug16k> er, the other way around
00:24:24 <stuff_is> since I just pass some pointers to fill data in memory with stuff I need, I mean I just take an address after the code and just add some stuff just to be sure
00:24:35 <doug16k> then all your code is right then
00:25:07 <stuff_is> I don't think it is, I think there are some cases I forget to reset registers to correct state, it's very coumbersome for me to keep track of stuff all the time
00:25:15 <doug16k> if I knew it was fine I would have saved myself a lot of typing
00:25:29 <stuff_is> I mean I know there is pusha popa, but there are cases where I have to switch between my segment and the VBE segment in qemu is the same but I am not sure if it's always
00:26:17 <stuff_is> well I mean I accidentally made it work on my laptop, and it always worked on qemu, I have no idea why setting ss to 0 made it not work, and I am not sure if it;s exactly that, or maybe it's related to you saying about uninitialized data
00:28:05 <stuff_is> it wasn't fine tho, at least outside qemu, I managaed to make it work by commenting stuff at random and thinking since after my first print I have a call it must be related to the stack maybe
00:28:14 <stuff_is> that's how I manage to make it work not only in qemu too
00:30:04 <stuff_is> brb gonna try one last test
00:34:34 <stuff_is> I have to go to sleep because it is very late and am very tired and dont think I can figure it out today
00:35:13 <stuff_is> but your intuition is very correct, it is not related to mov ss but to the size of the code? IDK but adding the mov ax instruction before (Which used to be mov,0) breaks it
00:35:25 <stuff_is> it seems to be related to maybe uninitialized data as you thought
00:35:43 <doug16k> a debugger can reveal the mystery
00:35:51 <doug16k> have you stepped through it?
00:35:55 <stuff_is> sorry and thank you for your help, I'll investigate this, IDK if I can figure it out tho, I mean adding a mov
00:36:14 <stuff_is> not yet, I have yet to learn how to use a debugger with qemu, I was told it's not even possible in 16 bit mode
00:36:17 <doug16k> ask about gdb debugging qemu when you are ready. it's easy
00:36:58 <doug16k> not possible is an exaggeration. not perfect is more accurate
00:37:07 <stuff_is> thank you, I will, I have to sleep so late and so tired
00:37:30 <stuff_is> but it's almost magical how adding an instruction that seemingly does nothing can have such a profound effect
00:37:52 <doug16k> yeah. that is what makes it hard
00:37:53 <stuff_is> I can probably add nops there and it should fix it too maybe, if it's the right number
00:38:09 <doug16k> when it fails when it is wrong, that's great. makes it easy. the trouble is when it doesn't fail (yet) when it is wrong
00:38:28 <doug16k> that makes it very hard
00:38:47 <stuff_is> and the behavior is so strange, it just prints the first line again, but this time since I made some changes its not exactly the first, but with a bit of curruption
00:38:48 <doug16k> "works" is not "correct". don't let yourself believe that it is working therefore it is correctly implemented
00:39:37 <stuff_is> well I mean compared to the broken version it gets into protective mode and fills half the screen in red, I mean it's still an incorrect program, but it's much closer to the desired behaviour, or maybe in some cases it does what I want, cause of good circumstances
00:39:54 <doug16k> always be open to the possibility that it is wrong, and when you change it to be right, it unmasks a bug elsewhere. this change seemed to break it, but this change is right, you just uncovered another bug when you corrected this one
00:40:23 <stuff_is> you have such great intuition, I was convinced it was related to ss, but since you talked about instruction size , I added a mov just in case
00:40:48 <stuff_is> I mean I was convinced cause me commenting the line seemed to fix the issue, but I missed completely the point
00:41:23 <doug16k> at first everything is all touchy like this
00:42:04 <doug16k> once you build up a bit of a platform, the totally mysterious baffling seemingly impossible behaviour goes away
00:42:06 <stuff_is> thanks a ton for your help, and sorry about perhaps being annoying and whatnot, I will have to investigate this and try to understand why it happens after I sleep, because it's so strange why it behaves like this, I have absolutely no idea why it prints the same line twice, very strange behaviour
00:42:22 <stuff_is> and you said to step in a debugger, but I just realized something unfortunate, it works in qemu but not on real hardware
00:42:28 <stuff_is> so I guess it's gonna be harder to investigate
00:42:57 <doug16k> how much room is left in your sector?
00:43:25 <stuff_is> IDK plenty, my sector loads anotehr 4 and jumps to second stage as soon as possible
00:43:29 <doug16k> add 10 nops (try a few different places) and see if you can make it happen on qemu
00:43:46 <stuff_is> I mean I fill it with 0 then the signature for MBR, but useful code is not much, like 200 bytes maybe even less
00:43:57 <doug16k> you can fill qemu memory with initial garbage too, with command line options
00:44:24 <stuff_is> can the issue be in second stage bootloader? I'd have to maybe comment the jump and see that as well, if it's in first stage it's probably gonna be easier to find out, since it's so short
00:44:42 <doug16k> issue can be anywhere
00:44:58 <doug16k> the slightest thing could be it
00:45:45 <stuff_is> well ty, I will write some notes, and do this, sorry very tired today, it's like past 3 in the morning here
00:46:02 <stuff_is> thanks again, and goodnight
00:46:06 <doug16k> it's a good idea to take your final bin, disassemble it, and run it with your eyeballs and make sure it really put down what you said
00:47:15 <stuff_is> took actual notes of your suggestion will look into this :D
00:47:19 <doug16k> and at the beginning, consider every register undefined except dl and cs is either 0x7c0 or 0x0
00:47:39 <doug16k> see if it can reach somewhere that hasn't written a value to that register yet
00:47:40 <stuff_is> might be rudimentary but I mean I often debug by commenting code, adding extra prints, doing some manual bad almost binary search...
00:48:26 <doug16k> you could debug it in qemu, set all the registers except edx and cs to some crazy value, and step that
00:48:50 <doug16k> setup the initial crazy register values before the first step
00:49:18 <doug16k> (after it hit the breakpoint you hit from executing 'b *0x7c00' 'c'
00:51:28 <stuff_is> ty, will look into it after I sleep, sorry have to go, goodnight
00:57:15 <doug16k> clever, that weird UNRELOCATED thing is compensating for code linked at 0x600, that's running at 0x7c00. asap it moves itself to 0x600 and stops compensating
00:57:50 <clever> yeah, i got that part, stage2 is running from the "wrong" address (relative to what you told ld about)
00:57:59 <doug16k> at first ya
00:59:22 <doug16k> my mbr is relocated to 0x600. my chainload boot sector is relocated to 0xF000, and my actual 32 bit protected mode bootloader stage is at 0x1000
00:59:41 <doug16k> last one is loaded in the right place to begin with, no UNRELOCATED
01:00:05 <doug16k> giving max bootloader size of 60KB. plenty
01:01:40 <doug16k> for fun I restrict myself to 8088 instructions until it gets into the PM phase, and check for 8088, 80286, etc and show message saying that specific cpu can't run it :)
01:02:35 <doug16k> well, it checks before PM obviously. transition to PM is in there
01:03:11 <doug16k> no cheating with 32 bit instructions: https://github.com/doug65536/dgos/blob/master/mbr/mbr.S#L101
01:03:12 <bslsk05> github.com: dgos/mbr.S at master · doug65536/dgos · GitHub
01:39:23 <doug16k> wow. I just tried my mbr boot. seems my final stage bootloader has grown just enough to smash the stack used by BIOS to do disk I/O. moved stack to top of 1st 64KB the end of 4KB at 0xF000
01:40:15 <doug16k> I have half a mind to go against my suggestion and make the entire second 64KB the stack
01:40:39 <doug16k> i.e. put 0x1000 in ss and 0 in sp
01:41:06 <doug16k> and tolerate the most stack hungry bios imaginable
01:44:22 <doug16k> did it :)
01:48:29 <doug16k> thankfully seabios uses a lot of stack to reveal the issue
02:46:46 <doug16k> every time I run into a regression like that I get a renewed determination to make an automated test pass that tests every possible boot, but never get around to it
02:48:38 <doug16k> bios cd / hd / pxe. efi cd / hd / pxe. and that whole matrix with os drive on ide / ahci / nvme / usb / virtio / ... you get the idea
02:49:57 <kingoffrance> vga i2c, sound card, yeah
02:50:03 <kingoffrance> mic in
02:50:23 <kingoffrance> dtmf boot
02:51:10 <doug16k> I generate 11,520 different ways to start qemu in my makefile
02:51:20 <doug16k> literally
02:51:37 <kingoffrance> what is that for?
02:53:15 <doug16k> {debug|run|trace|asan|tracedbg}-{up|smp|numa}-{bios|efi}-{pxe|hd}-{iso|mbr|gpt|hyb}-{none|ahci|ide|nvme|usb|virtio}-{vga|gl}-{kvm|icount|tcg|mttcg}
02:54:41 <doug16k> so I can test, say, cd boot on uniprocessor with IDE drives, or EFI hard drive boot on smp with AHCI,
02:55:22 <doug16k> in kvm or single or multithreaded tcg emulation or icount deterministic execution
02:55:57 <doug16k> not all combinations make sense, but most do. cd boot on nvme is nonsense
02:57:07 <doug16k> "gl" means virtio-gpu
02:59:19 <kingoffrance> ah, makes sense
02:59:29 <kingoffrance> just was curious how it got >10k
02:59:33 <doug16k> 768 actual configurations, if you ignore the different launch methods and emulator modes
03:00:15 <clever> ive done similar for my kexec linux stuff: https://github.com/cleverca22/nix-tests/blob/master/kexec/simple-test.nix#L67-L75
03:00:16 <bslsk05> github.com: nix-tests/simple-test.nix at master · cleverca22/nix-tests · GitHub
03:00:24 <clever> but its only 7 tests
03:01:16 <kingoffrance> kexec as in you can load a new kernel from a prior one?
03:01:21 <clever> yeah
03:01:40 <clever> but the main things its testing, is the script to wipe your hdd, and install an os, without interaction
03:01:53 <clever> and kexec is just used to let you wipe the disk, and not have it mounted
03:01:57 <ronsor> I have a strange idea
03:02:03 <ronsor> kexec() from Linux to my kernel
03:02:40 <clever> ronsor: likely possible, the assembly bridge between kernels, is generated in userland when you load the kernel
03:02:52 <clever> i have seen kexec break, when the kexec userland tools got compiled with gcc hardening
03:03:00 <kingoffrance> not so strange -- oldworld mac mklinux was mac os -> mach -> linux i think beos ppc too, mac os -> beos
03:03:09 <clever> so you just need to look at how the kexec api works
03:03:13 <kingoffrance> non-be hw anyways
03:04:10 <clever> i lost the link, but i also looked into kexec for linux->mac, mac->linux and mac->mac i think
03:04:27 <kingoffrance> old things like drivers i think youd sometimes even dos -> bsd,linux just to run some "device setup" program first
03:05:16 <doug16k> I had to draw a spy plane to get make to generate all the rules: https://github.com/doug65536/dgos/blob/master/Makefile.am#L2691
03:05:18 <bslsk05> github.com: dgos/Makefile.am at master · doug65536/dgos · GitHub
03:05:45 <clever> lol
03:05:54 <ronsor> could just be the easiest way to have people install my OS
03:06:20 <clever> ronsor: some things like the GPU often dont survive kexec, so you need to reboot to fix it
03:06:42 <ronsor> it would be used to run a small demo or installation wizard
03:06:51 <ronsor> not as a regular bootmethod
03:07:09 <clever> that would only work if the gpu is still usable
03:07:28 <clever> i was recently re-reading https://web.archive.org/web/20180223072827/https://www.rano.org/bcompiler.html
03:07:31 <bslsk05> www.rano.org: The page you're looking for could not be found (404)
03:07:41 <clever> a blog post on bootstrapping a compiler from raw asm
03:07:44 <kingoffrance> it is kernel re-entrancy in a way i suppose
03:07:58 <clever> and then i packaged it for nix, lol: https://github.com/cleverca22/bcompiler/blob/master/default.nix
03:07:59 <bslsk05> github.com: bcompiler/default.nix at master · cleverca22/bcompiler · GitHub
03:08:16 <ronsor> new idea then
03:08:22 <ronsor> migrate the running kernel and system to a VM
03:08:30 <ronsor> and then use its drivers
03:09:00 <clever> ronsor: thats basically malware at that point
03:09:09 <clever> rootkit the kernel :P
03:09:37 <ronsor> not malware if the user wants it
03:09:51 <ronsor> unless i make some sort of malware to install my OS
03:10:54 <kingoffrance> https://www.fabiankeil.de/gehacktes/electrobsd/ see 10. Start clown-computing with ElectroBSD
03:10:54 <bslsk05> www.fabiankeil.de: ElectroBSD - The might to deliver onions - Free as in free (electro) beer and freedom
03:11:01 <clever> your worst nightmare is malware getting into kernel mode, and then migrating your entire os into a vm
03:11:09 <kingoffrance> "If the hoster doesn't provide an ElectroBSD image (most currently don't), one can use these steps: "
03:11:14 <clever> so when you run any anti-virus, the malware can lie about everything
03:18:39 <kingoffrance> on a serious note, does anyone bother to get "reproducible builds" ?
03:18:51 <kingoffrance> i mean, i see the reasoning for it, just not high priority for me
03:19:47 <clever> kingoffrance: there is a flag for that in my package manager (nix)
03:20:10 <clever> i just set `repeat = 1` in the main `nix.conf`, and then it will repeat every build an extra 1 time, and diff the 2 builds
03:20:15 <clever> if its not reproducible, it will fail the build and delete all products
03:20:40 <clever> (when i say my package manager, i just use it, didnt create it)
05:18:11 <ronsor> I still hate my new VFS design
05:18:15 <ronsor> it seems so complex
07:14:18 <G3nka1> File systems use page caches for caching frequently accessed blocks, if I have two drives forming a single logical volume does the file system on top of it actively migrate data between the drives to provide max bandwidth?
07:15:13 <zid> depends what level it's logically connected on
07:15:28 <zid> if it's just raided together then you'll get the semantics of the raid, etc
07:16:07 <G3nka1> Lets say its not RAID zid, for now my goal is to maximize throughput.
07:24:42 <G3nka1> I mean are requests to file system concurrent or can they be parallel?
07:26:01 <zid> if they were parallel you'd only be able to run one program at once
07:26:13 <zid> err serial
07:26:15 <zid> you said parallel twice
07:33:13 <G3nka1> My bad I was talking in the context where concurrency is executing multiple tasks but not necessarily simultaneously whereas parallel is when tasks run simultaneously on two different cores at the same time. zid
07:35:05 <G3nka1> So two FS using two kernel threads to handle two different requests on two cores is possible I guess
07:35:31 <G3nka1> *So a FS
07:39:38 <doug16k> concurrent and parallel are different things
07:40:33 <doug16k> concurrent means overlapping things in time. parallel means doing more than one thing at the same time
07:41:04 <doug16k> one thread doing a bunch of async I/O is concurrent. multiple threads doing a bunch of async I/O is parallel and concurrent
07:41:51 <doug16k> parallel assuming you can run them both at one time on different execution hardware
07:43:04 <doug16k> s/both //
07:43:26 <G3nka1> Thats for elaborating that doug16k, does ext4/XFS/BTRfs support parallel I/O threads?
07:43:37 <G3nka1> Was my initial question.
07:48:31 <G3nka1> S/Thats/Thanks
07:49:46 <zid> in reality, we use drives with command queues
07:49:51 <zid> since the early 00s
07:50:01 <zid> so you submit multiple jobs to the drive regardless
07:50:13 <rhn> I don't think it's up to the FS to decide between parallel-concurrent, it's the hardware device which is the bottleneck
07:50:17 <zid> it has a cache and knows where the heads are, so it's better to give the drive as much as you can
07:50:22 <zid> and let it feed you from cache while it's seeking, etc
07:50:49 <zid> rather than just dumbly feeding it commands in the order you got them, waiting for an ack between each etc
07:51:03 <rhn> ^this, and this seems concurrent but not parallel to me
07:51:56 <rhn> SSDs have a level of parallelism, but I don't think they expose any info about that to the OS at the moment
07:52:08 <rhn> so again not up to the FS to decide
07:52:50 <rhn> RAID would be relevant - would have to ask about dmraid, or how btrfs does its "RAID"
07:53:24 <rhn> I know for certain that btrfs RAID1 doesn't try to read from the 2nd copy
07:53:25 <G3nka1> rhn: open channel SSDs do, but I get your point
07:54:07 <rhn> G3nka1: thanks, I didn't know it had a name
08:00:37 <kingoffrance> it would seem to me: drive/hw multipathing filesystem each of these layers, maybe more, potentially can have their own versions of stuff plus possible RAID too, hw or sw
08:00:51 <kingoffrance> and then add "network" on the end as another layer
08:00:52 <G3nka1> Also rhn, I am thinking parallel access across drives so even if SSD parallelism is not available for OS.
08:01:27 <kingoffrance> well, "network" could be "before" or "after" fs of course
08:01:38 <rhn> G3nka1: look at the RAID layers then
08:02:45 <G3nka1> rhn: right raid is static data, I am thinking of dynamically migrating data across drives to increase bandwidth for a particular workload
08:03:27 <rhn> btrfs would be able to do that I guess
08:03:37 <rhn> it's not quite RAID
08:04:02 <rhn> zfs probably also
08:04:29 <G3nka1> I see, let me study btrfs and ZFS, I don't necessarily need RAID
08:04:47 <rhn> I don't think they have anything resembling a migration manager, and I'm not sure they actually leverage parallelism
08:05:52 <G3nka1> This seems exciting :)
08:06:25 <rhn> for your particular problem, I would also think about placing a fast SSD as a block cache before your larger file system if your fast data set isn't very big
08:08:00 <G3nka1> That'll be a good optimization, I will think about it.
08:09:21 <clever> zfs does that as well, they call it the L2arc
08:09:37 <clever> it basically acts as a swap device for the page cache, and is lost upon shutdown
08:10:12 <clever> but unlike swap, it doesnt cache writes, and under low-memory conditions, the ram cache can just discard pages, and not wait for writes to l2arc
08:10:34 <clever> so l2arc writes are fully async, and wont block any "oh god, i need moar ram" conditions
08:14:33 <G3nka1> Thanks for the reference clever
09:54:07 * gog meows
09:54:36 <gog> too early for a sunday to be awake already but here we are
12:59:10 <konfujen> gog: report
13:06:11 <konfujen> gog: what's your status?, over.
16:39:29 <siberianascii> gog: may the phoss will be with ya
16:57:50 * geist yawns
16:59:00 * siberianascii im thinking of my onw line
17:01:29 <zid> I rewrote my LCD for my gameboy and broke it
17:01:50 <zid> https://cdn.discordapp.com/attachments/465586075830845475/739528196864868443/unknown.png The bottom octorok is now.. a black mush
17:02:12 <geist> you broke your code or the gameboy ?
17:02:19 <zid> yes, yes
17:02:23 <zid> my code being the gameboy
17:05:25 <siberianascii> zid: do you really have a gameboy ?
17:15:22 <geist> wonder how rare original gameboys are nowadays. they were all over the place when i was a kid
17:15:28 <geist> never actually had one
17:16:07 <siberianascii> though childhood i bet...
17:16:44 <geist> well yes.
17:16:50 <siberianascii> sure ...
17:17:47 <zid> They're fairly expensive now, but replacement and reproduction parts are everywhere
17:18:03 <geist> yah i'd say they're rare. but they made a bazillion of them
17:18:05 <zid> The 'original' gameboy was 8 revisions by itself, like 1 year from 89 to 97
17:18:08 <geist> they were mega popular at the time
17:19:23 <zid> gb and gbc combined sold 120M units
17:19:27 <zid> they're.. pretty common
17:30:07 <siberianascii> gog: i can't hear ya
17:31:47 <geist> huh?
17:33:34 <siberianascii> geist is DDD is useless ?
17:33:53 <siberianascii> i mean can i roll only with gdb ?
17:35:08 <siberianascii> dann halt nicht..
17:38:26 <siberianascii> geist seriously why are you so dick ? ( no pun intended )
17:40:03 <geist> what?
17:40:13 <geist> what the heck are you going on about?
17:40:18 <siberianascii> i mean..
17:40:39 <siberianascii> i talk to gog and you "huh ?" me
17:40:55 <siberianascii> not cool... boy
17:41:03 <geist> okay, i'm done
17:42:17 <siberianascii> please explain your action geist
17:42:37 <siberianascii> this is geekhood brutality
17:42:40 <geist> insult me and you're out
17:42:48 <geist> so cut it out
17:42:55 <siberianascii> you insult me
17:43:13 <siberianascii> "huh ?" like im some drug kid from compton
17:43:26 <geist> huh like where's the other end of this conversation
17:43:29 <siberianascii> even if it's true.. and im admit nothing btw....
17:43:43 <siberianascii> thats not cool
17:43:47 <geist> too bad.
17:43:51 <siberianascii> ??
17:43:53 <siberianascii> what bad
17:44:03 <geist> not gonna engage. just go away
17:44:50 <siberianascii> gog:
17:45:33 <geist> if you wanna chat with gog do it in private
17:45:47 <siberianascii> he dont answer me
17:46:04 <siberianascii> i suspect he putted me on ignore
17:46:06 <gog> he can't i've ignored him
17:46:19 <geist> got it. so it's clear the gog is underested in hearing from you siberianascii
17:46:27 <geist> so. stop using this channel for it
17:46:51 <siberianascii> enough is enough...
17:47:03 <siberianascii> i got scratches all over my face from that cat
17:47:21 <siberianascii> gog: now you gonna see my dog
17:47:31 <geist> did you just threaten gog?
17:47:56 <siberianascii> yes with my dog
17:48:03 <gog> lmfao what
17:48:26 <geist> i dunno, i think he's done now. hasn't contributed and ust comes in drunk or whatever and mews on gog
17:48:29 <geist> sorry about that
17:49:22 <Belxjander> well...done and done then
17:49:35 <Belxjander> geist: ever deal with unicode libraries much?
17:49:58 <geist> Belxjander: hmm! not really. no. i had to deal with unicode a bit in some FS stuff years ago when i worked at apple
17:50:02 <geist> but it was also kinda a nightmare
17:50:16 <Belxjander> ahhh
17:50:21 <uplime> what did you do at apple?
17:50:28 <geist> but that was mostly normalization and whatnot
17:50:53 <geist> uplime: i worked thee for a couple years in 2005-2007. did some FS stuff and then got pulled into the iphone project since i was handy with ARM
17:51:05 <uplime> oh neat
17:51:14 <uplime> im a big fan of your work then i guess
17:51:17 <gog> Belxjander: what's the issue? i might have some insight
17:51:24 <gog> big if true tho
17:52:03 <Belxjander> gog: mainly needing to work out how to setup rules to cover unicode ranges based on a plugin model...
17:52:14 <Belxjander> where each plugin provides language specific rules
17:52:37 <Belxjander> what I did have in mind has to be replaced :/
17:52:53 <geist> uplime: yah it was a neat time. was also a real meat grinder which is why i left after a while
17:52:53 <gog> is it something like bidirectional text and such?
17:52:59 <geist> but it was an interesting time at least!
17:53:08 <Belxjander> gog nah... not the display end but the input end...
17:53:13 <gog> ohhhh
17:53:22 <Belxjander> needing to deal with IME behavioural rules when generating Unicode
17:53:28 <gog> that's not something i'd have much insight on
17:53:55 <uplime> geist: yeah i bet. i'm not sure what its like to work at apple but the iphone has always seemed interesting from a security/os perspective, since it seems to work differently from most others
17:54:43 <Belxjander> gog: Im trying to sort out how to properly wedge an IME into an OS setup that originally only had a raw keyboard feed into the UI subsystem
17:55:31 <Belxjander> one thing I do have to work on is attaching to the string input widget properly as well
17:56:16 <Belxjander> basically needing an idea where to start again at this point
17:57:05 <gog> is the raw keyboard feed scancodes or is it mapped text?
17:57:33 <gog> is it processed in any way between the kernel driver and the UI?
18:03:38 <Belxjander> "keyboard.device"->"input.device"->"console.device" or "intuition.library"
18:04:09 <Belxjander> where "input.device" is a messaging subsystem for ALL input as "event" based processing
18:04:49 <Belxjander> I can capture ALL keyboard input and feed my own events using input.device IO
18:06:37 <gog> perhaps you can wedge the ime between input.device and console.device
18:07:01 <gog> and do the input method stuff in the input subsystem
18:07:10 <gog> unless you tried that and failed :p
20:08:10 <anontt> is anyone familiar with this tutorial, is it any good? https://michelizza.developpez.com/realiser-son-propre-systeme/#LI
20:08:18 <bslsk05> michelizza.developpez.com: Réaliser son propre système
21:08:57 <sortie> Ah they left but it's not. It doesn't mention a cross-compiler and lots of other good practices.
21:09:30 <sortie> For the record, although most people would know it by now, https://wiki.osdev.org/Bare_Bones is our recommended introductory tutorial that ensures a proper setup
21:09:32 <bslsk05> wiki.osdev.org: Bare Bones - OSDev Wiki
21:25:03 <doug16k> system management mode won't cause a hlt to wake up. the cpu crawls back into the hlt on RSM as if nothing happened, when hlt is preempted by SMI
21:38:27 <geist> ah interesting, figured it might bop it out
21:38:59 <geist> but i guess maybe it does break it out in the same way a VM would if it vmexited, but since it resumes by starting the instruction over again i guess it appears to still run
21:39:39 <geist> but then i guesa a VM wouldn't ever return back into a hlt, because the whole point is not to halt the cpu on a vm
21:39:47 <geist> but SMI would because what else is there to do?
22:17:44 <doug16k> the jmp is still needed for the NMI though (re: the wiki page)
22:18:41 <doug16k> it's impressive how stealthy they made SMI
22:20:02 <doug16k> it won't disturb the state at all, it only makes code sequences appear to take longer sometimes
22:20:42 <doug16k> I suppose it disturbs the cache state a bit
22:30:12 <unlord> hi
22:30:34 <unlord> I'm writing some code to parse the ACPI tables and attempt to wake multiple cores
22:54:53 <doug16k> unlord, nice
22:55:31 <unlord> doug16k: how often is the RSD PTR in the first 1k of EBDA ?
22:57:46 <doug16k> why does it matter? there are two regions to check
22:59:14 <unlord> my code that just checked 0xe0000 to 0xfffff failed
22:59:52 <doug16k> 1) make a thing that searches a given range of addresses, 2) call it once for EBDA, and once for 0xE0000-0xFFFFF, make it return true if it found it and skip 2nd one
23:00:03 <unlord> yeah, I'm working on it
23:00:14 <doug16k> https://github.com/doug65536/dgos/blob/master/boot/boottable_bios.cc#L102
23:00:15 <bslsk05> github.com: dgos/boottable_bios.cc at master · doug65536/dgos · GitHub
23:01:19 <unlord> fancy :)
23:02:04 <unlord> so this code is already in 32-bit mode
23:02:20 <doug16k> yes
23:02:41 <doug16k> my bios bootloader runs in 32 bit PM, efi one runs in long mode
23:02:56 <doug16k> efi does this: https://github.com/doug65536/dgos/blob/master/boot/boottable_efi.cc
23:02:57 <bslsk05> github.com: dgos/boottable_efi.cc at master · doug65536/dgos · GitHub
23:03:13 <unlord> cool
23:45:51 <unlord> doug16k: bochs found it at f000:a170 and virtualbox at e000:0000
23:46:50 <doug16k> which is great. it would shake out a bug where one works and the other doesn't
23:47:44 <unlord> yep, and now I get to debug more things, but this is a start