klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
netbsduser` has quit [Ping timeout: 246 seconds]
Lucretia has quit [Remote host closed the connection]
<heat> zid, they never did need to redesign huge bits of it
<heat> as far as i understand they hacked a bunch of stuff up for android, a large number of patches that then sucked to rebase on top of upstream
<heat> but then fucked it up even harder so OEMs added their own patches on top
<heat> now OEMs can't modify the core kernel and android only accepts most patches after they hit upstream
<zid> comparitively huge
<zid> not actually huge lol
<zid> I bet the android patch series's's' are small and inoffensive compared, these days
<bslsk05> ​android.googlesource.com: android-mainline - kernel/common-patches - Git at Google
<heat> still looks bad but not as bad as before i guess
<zid> I think gentoo has more patches than that :p
<zid> ah it's pretty clean rn
<bslsk05> ​gitweb.gentoo.org: proj/linux-patches.git - Linux patches
<heat> arch has like... 3 or 4 patches
<zid> patch 4 is the one that makes you say "I use arch btw"
<heat> no they actually all suck
<nikolar> what are the patches
<zid> oh all 4 patches do it
dysthesis has joined #osdev
<bslsk05> ​github.com: Release Arch Linux kernel v6.12.10-arch1 · archlinux/linux · GitHub
<zid> those are infact, bad
<nikolar> zid, you were right
<nikolar> one was indeed "i use arch"
<zid> and it was patch 4 lol
<nikolar> lol
<heat> the zen kernels are total crap btw
<nikolar> how so
<nikolar> i've never really looked into them
<heat> they include unfinished work in their tree
<heat> which may or may not be correct
<nikolar> neat
ThatOSDeveloper has joined #osdev
<ThatOSDeveloper> Hi
<pog> hi
<heat> like they included the really new amd invlpgb patches that weren't even properl reviewed or included uptream at that point in time
<nikolar> kekker
<nikolar> s
<heat> for something that's really unlikely to ever be noticed by "desktop users"
<ThatOSDeveloper> any advice on interrupts? I am trying to get them to work but for some reason int_num is some random number at like 16K whatever lol
<heat> no desktop user will be like "hey bro my tlb flushes are too slow"
<zid> and what is int_num
<childlikempress> thats because desktop users are
<childlikempress> STUPID
<heat> that would make sense if you're using FRED
<heat> (please disregard, is a joke)
<ThatOSDeveloper> it is the interrupt number passed to my handler via a frame with registers stuff (at the time of calling my handler) and so on.
<heat> gotta link the codez man
<nikolar> heat: wasn't fred dead?
<heat> no
<zid> no
<nikolar> or was it x86s
<ThatOSDeveloper> alr imma link
<heat> x86s is ded
<zid> x86s is dead
<nikolar> ah that's it
<nikolar> wonder if we'll get actual fred hardware
<nikolar> or apx hardware
<ThatOSDeveloper> the link is https://github.com/SlugOS/SlugOS
<bslsk05> ​SlugOS/SlugOS - A minimal OS (0 forks/0 stargazers/CC0-1.0)
edr has quit [Quit: Leaving]
<zid> ThatOSDeveloper: Sounds like you read the stack wrong then? did you push 1 / push 2 / push 3 etc at the start of an otherwise generic handler or osmething then try to pop it off?
<heat> gotta pray and fast for intel
<ThatOSDeveloper> oh crap I never pushed it LOL
<ThatOSDeveloper> wait no I did
<zid> where am I looking
<zid> ah, init
MiningMarsh has quit [Ping timeout: 252 seconds]
<ThatOSDeveloper> inside of src/init/interrupt and inside of isr.s and exception.c
<heat> well for one there's a big problem
<ThatOSDeveloper> what?
<heat> in that you never pop the state back out
<ThatOSDeveloper> oops
<zid> biggest problem I noticed is that you have your * on the wrong side of this char
<ThatOSDeveloper> kinda new to assembly lol
<zid> disgraceful behaviour
<ThatOSDeveloper> and eh with C, I mean I am mid with it, only known it for a few years
<heat> isr_no_err_stub never pushes anything either
MiningMarsh has joined #osdev
<nikolar> * IN WRONG PLACE???
<zid> nikolar: I've already called the police
<nikolar> ah good
<ThatOSDeveloper> ... *takes out bomb*
<zid> void exception_handler(exception_frame_t *frame) {
<zid> shouldn't this be
<heat> your stack doesn't match the struct
<zid> void exception_handler(exception_frame_t frame) {
<heat> also yes
<ThatOSDeveloper> wait wat
<heat> but really you want to pass a pointer
<ThatOSDeveloper> so let me try and fix it
<zid> what convention are we using
<pog> all you do is push esp
<zid> you need to match it on both sides
<ThatOSDeveloper> waht do you mean match it on both sides, like push esp first and match that in my struct and assembly?
<pog> should i start working on my os again
<heat> pog, yes
<ThatOSDeveloper> yes pog, you must
<pog> no, push esp because it'll become the argument
<pog> in cdecl
<zid> ThatOSDeveloper: I mean the way you deliver args should be the same as the way exception_handler retrieves them
<zid> as written, you told it that the function reads a single pointer parameter from.. the top of the stack, maybe?
<zid> depending on calling convention
<ThatOSDeveloper> zid: this makes no sense to me, so how do I do it?
<childlikempress> pog: os development is for losers
<childlikempress> make a compiler insted
<heat> FUCK YOU ORI LAHAV
<zid> ThatOSDeveloper: First, you look up the convention we're using it, then you follow it, lol
<pog> childlikempress: i'm too dumb to mak ea compiler
<heat> STICK YOUR MEMORY MODELS UP YOUR-i need to calm down
<nikolar> childlikempress: heat thinks compilers are lame, tell him that he's lame instead
<pog> i'm a web dev
<ThatOSDeveloper> zid: calling convention? I am lost here (sorry I am in the land of USA so our education is not good lol)
<childlikempress> heat: paulmck also makes memory models
<childlikempress> ROASTED
<zid> The convention used
<childlikempress> BITCH
<zid> for calling
<nikolar> lol
<heat> childlikempress, BASED paulmck memory models i must add
<nikolar> helpful as always zid :P
<ThatOSDeveloper> oh yeah, I guess I am using cdecl?
<kof673> * united states federal territory, they don't claim the land per se...federal territory is defined as outside any of the geographical states :D
<zid> for example, the only one I ever remember off the top of my head, rdi = first parameter, rsi = second parameter, rdx = third parameter, ..., stack aligned to 16
<zid> okay so cdecl says your args are on the stack
<ThatOSDeveloper> oh, now I think I know what you mean
<zid> you've pushed like 12 args, then retrieved 1 arg
<zid> a pointer
<ThatOSDeveloper> so do I just need to push like ebp (the stack frame)
<nikolar> zid: pretty sure that's sysv
<nikolar> rdi, rsi, rdx, rcx
<ThatOSDeveloper> or is ebp the stack pointer?
<nikolar> stack
<heat> no, push esp
<ThatOSDeveloper> oh esp okay
<heat> also, your order is completely fucked
<nikolar> esp - stack pointer
<nikolar> ebp - base pointer
<zid> you either want to do void exception(int arg1, int arg2, int arg3, int arg4, ...) or actually push esp first, so that your first thing on the stack is infact, a pointer to all that other crap :P
<zid> I recommend the latter
<ThatOSDeveloper> so I would need to do push %esp?
<zid> s/first/last
<heat> yes
<ThatOSDeveloper> okay then I push all the other stuff?
<zid> push esp just copies the current (which is the 'end') value of the stack pointer, to the stack, making it the first argument to your function call, and at the 'end' of the stack, is all the other crap you pushed to it
<heat> no!
<zid> push esp last, it needs to be the first argument to your function, and it needs to have the address of 'all the other crap'
<nikolar> no! = NaN
<heat> nikolar, js?
<ThatOSDeveloper> right because assembly does it backwards compared to C right!
<heat> ThatOSDeveloper, i think you dont understand the stack
<zid> if you pushed it first, its value would be the saved eip of the assembly routine or whatever
<heat> you really need to
<nikolar> heat: just in general
<nikolar> no is indeed not a number
<nikolar> neither is no!
<ThatOSDeveloper> listen man I barely understand C let alone assembly, I am impressed I even got this far on my own
<heat> ok, then understand the stack
<zid> You might wanna look at godbolt more, in future
<bslsk05> ​godbolt.org: Compiler Explorer
<ThatOSDeveloper> so if I push it last, it is the very top of the stack which then goes to the function right?
<ThatOSDeveloper> well goes to the function first
<zid> the last thing you pushed is the first thing to be popped, yes
<heat> yes
<ThatOSDeveloper> so do I need to pop it after exception handler?
<nikolar> yes
<heat> and the way you're pushing things will come up with a very broken stack frame
<zid> cdecl says if you should or should not
<ThatOSDeveloper> heat: sounds about right
<ThatOSDeveloper> got to admit, I got pretty far on my own.
<heat> you need to push in reverse wrt the struct
<heat> like, the stack grows down right?
<zid> stack cleanup column for cdecl in the wiki page: caller
<heat> and C structs grow up
<heat> so, looking at exception_frame_t, ds needs to be the last thing you push
<zid> so the caller needs to remove the parameters, your pushed esp, but then you also need to remove that temporary local struct you made in the callee
<heat> then eax, then ecx, then edx, yadda yadda
<ThatOSDeveloper> so if I push all my stuff first (in the code) then at the end of my code (right before exception_handler is called)
<heat> last thing you push *before the push %esp for the argument*
<ThatOSDeveloper> so I want to push all of my crap, then esp, then call the function, then pop it all?
<zid> yes
<heat> nice dog btw
<zid> normally you could use ebp to achieve that, but if you use ebp, you'll corrupt it
<ThatOSDeveloper> so do not push ebp
<zid> you can push it, that only changes what's on your stack
<ThatOSDeveloper> so pushing it changes it?
<zid> you can push it, that only changes what's on your stack
<ThatOSDeveloper> oh lol
<zid> You need to *not* corrupt ebp, inside an interrupt handler
<zid> so you can't do the usual mov ebp, esp; push esp stuff
<ThatOSDeveloper> wait did I do that?
<zid> That's what almost all cdecl functions do
<heat> no you did not
<zid> Your problem appears to be reading comprehension
<zid> [01:32] <zid> normally you could use ebp to achieve that, but if you use ebp, you'll corrupt it
<zid> NORMALLY ONE COULD, PLEASE DO NOT
<ThatOSDeveloper> I think I got it, I am going to try and make those mods now, so just in case, if a C stack grows upwards, if I do it in assembly, I would need to push it the exact opposite way?
<zid> C doesn't have a stack
<heat> yes
<ThatOSDeveloper> okay thank you
<heat> a C *struct* goes upwards
<heat> an x86 stack grows downwards
<ThatOSDeveloper> yes struct is what I meant
<zid> ah yes, compounds/arrays, go forwards
<zid> a[0] is before a[1]
<zid> a.member0 is before a.member1
<heat> note: you do not need to pop your arguments
sbalmos has quit [Quit: WeeChat 4.5.1]
<ThatOSDeveloper> does pushf push eflags?
<ThatOSDeveloper> I think it does
<heat> you dont need to pushf
<ThatOSDeveloper> okay but what does it do?
<heat> pushes eflags
<bslsk05> ​www.felixcloutier.com: PUSHF/PUSHFD/PUSHFQ — Push EFLAGS Register Onto the Stack
<zid> another resource you should be using
<heat> x86 has a well defined basic interrupt frame that iret pops
<heat> and is pushed by the cpu
<ThatOSDeveloper> really what is in it?
<heat> you should chec
<zid> the manual knows
<heat> the intel SDM knows, the osdev wiki knows
<heat> i also know but exercise left to the reader
<ThatOSDeveloper> (newline in barebones moment)
<zid> When an interrupt occurs, the new SS selector is forced to NULL and the SS selector’s RPL field is set to the new
<zid> CPL. The ol
<zid> you want this bit
<ThatOSDeveloper> eh I dont need eflags I think
<heat> spoiler: eflags is part of the basic x86 interrupt frame
<zid> figure 6-9
<ThatOSDeveloper> nvm then
<heat> and so is a bunch of other shit
<ThatOSDeveloper> like all of the e(letterhere)x things?
<zid> FIGURE 6-9
<ThatOSDeveloper> alr
<zid> open 325462-sdm-vol-1-2abcd-3abcd.pdf or whatever you have, go to approximately page 3212, and find figure 6-9
<ThatOSDeveloper> okay going to that page rn
<ThatOSDeveloper> does that explain the whole interrupt flag frame thing?
<zid> You made that term up, so I suspect not
<zid> never heard of a flag frame, interrupt or otherwise
<ThatOSDeveloper> I meant the things that the basic interrupt frame passes
<zid> FIGURE
<zid> 6
<zid> -
<zid> 9
<ThatOSDeveloper> looking for it RN
<zid> sounds more like to me that you were talking about 'flag frames' on irc
<zid> eyes must be playing tricks on me
<heat> you gotta read man
<ThatOSDeveloper> trying to find it
<zid> You've hit the limit of what you're going to achieve without doing it, and now you're massively behind, so, enjoy
<ThatOSDeveloper> yeah I suppose
<ThatOSDeveloper> oops scrolled over it, (at 8.1 now LOL)
<zid> also figure 6-4 has the same info
<zid> and is technically the correct one for you, I think
<ThatOSDeveloper> what version
<zid> all of them
<heat> gotta read man
<heat> please pleas eplease just read man pelase read PLEASE i mean PLEASE JUST READ
<ThatOSDeveloper> I mean like version 78 or like version 86 or which one of the manual ontent-details/671200/intel-64-and-ia-32-architectures-software-developer-s-manual-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html
<heat> fuck do you mean which version
<zid> it's a figure number, not a page number
<zid> it's the order the pictures are in, in chapter 6, interrupt handling
<zid> of volume 3
<ThatOSDeveloper> okay
<ThatOSDeveloper> looking thru it now
<ThatOSDeveloper> 6.14.5 Interrupt Stack Table got it
<zid> no, that's 6.14.5
<zid> you want FIGURE 6-4 or FIGURE 6-9
<ThatOSDeveloper> yeah figure 6-9 IS 6.14.5
<nikolar> kek
<zid> no, it is not
<ThatOSDeveloper> its just the image, but 6.14.5 explains it in words
<zid> 6.14.5 is a chapter, about the ia-32e stack table
<zid> in its own words "an alternative to the modified legacy stack-switching mechanism described above"
<zid> Above being the table I want you to look at, it's literally, 100%, NOT that
<zid> A) It's an entirely different method to the normal one and B) You're not in ia-32e mode
<ThatOSDeveloper> I thought ia-32e is just 32bit mode
<zid> Did you read that, in the manual
<zid> or did you just wildly guess, after assuming
<ThatOSDeveloper> I see your point now
<ThatOSDeveloper> but figure 6-9 covers the same thing and it says IA-32e and you told me to use it
<zid> it's pretty easy to guess what ia-32e means even, if you look at say
<zid> figure 6-9
<ThatOSDeveloper> I am looking at that, it still makes no sense to me
<zid> It describes two different stack layouts, one legacy, and one ia-32e, and the legacy one matches your registers
<zid> and the ia-32e matches different, extended, registers
<zid> that you don't have
<ThatOSDeveloper> oh that makes more sense, I assume legacy is just normal 32bit mode and IA-32e is 64bit mode (guess on regist starting with R like RSP and RFLAGS and such)
<ThatOSDeveloper> or 64bit registers
<zid> Yes, that is a MUCH better assumption
<ThatOSDeveloper> tysm for explaining that.
<zid> I really hate that I had to
<zid> you were trying to find if eflags was pushed or not, remember
<heat> i mean, that is okay, x86 is complicated
<ThatOSDeveloper> yeah it is, and well ARM is, ... far worse
<heat> arm is actually not worse
<heat> riscv is even simpler
<ThatOSDeveloper> riscv is good, but not really used anyware AFAIK
<ThatOSDeveloper> anywhere*
<heat> sure
<nikolar> riscv in, in fact, not good
<nikolar> it's a sucky arch
<nikolar> s/in/is
<ThatOSDeveloper> so if I push a stack I just need to push what is in figure 6-9?
<ThatOSDeveloper> (for a bare bones thing)
<heat> it was already pushed for you
<heat> you need to push the rest
<ThatOSDeveloper> oh that makes more sense
<heat> your exception frame struct is largely correct
<ThatOSDeveloper> oh thank god!
<ThatOSDeveloper> except for a bit of the order I assume
<heat> the order in the asm is completely fucked wrt the C struct
<ThatOSDeveloper> I am fixing that order now
<ThatOSDeveloper> and what do I push at the end?
<ThatOSDeveloper> it was ebp right?
<heat> wdym
<heat> esp
<ThatOSDeveloper> esp okay
<ThatOSDeveloper> so I tried to push in the right order but now I get 1166609477
<ThatOSDeveloper> for my interrupt number
<heat> pls show handlarz
<ThatOSDeveloper> its on the github page
<ThatOSDeveloper> src/init/interrupt
<heat> push $\number
<ThatOSDeveloper> oh
<ThatOSDeveloper> right
<ThatOSDeveloper> not used to GNU syntax (god I hate it)
<ThatOSDeveloper> but its better with C
vdamewood has joined #osdev
<ThatOSDeveloper> also doing it with $ I still get that weird 1166609477
<ThatOSDeveloper> I should be pushing it correctly
<heat> the order in which you pushed things is still wrong
<ThatOSDeveloper> do I have to do it backwards
<ThatOSDeveloper> ?
<ThatOSDeveloper> because I did
<ThatOSDeveloper> I think
<heat> edi, esi, ebp, ebx, edx, ecx, eax
<heat> this is all wrong
<ThatOSDeveloper> other way?
<heat> think about the layout of edi, esi, ebp, ebx, edx, ecx, eax in the struct
<heat> and now try to match that up with the exception frame
<ThatOSDeveloper> so I need to do it in the same order in ASM even tho I was told to do it backwards since how pushing and such work?
<ThatOSDeveloper> (in ASM)
<heat> no
<ThatOSDeveloper> so I still do it backwards?
<ThatOSDeveloper> I am so lost
<heat> understand what the layout of that C struct is
<heat> and then do it fucking backwards
<ThatOSDeveloper> oh, I assume I did not do it backwards? I got lost for like 5 mins when doing the ASM part lol
<heat> edi, esi, ebp, ebx, edx, ecx, eax is wrong
<ThatOSDeveloper> it should be backwards shouldn't it
<ThatOSDeveloper> I will get started on that
frytaped has joined #osdev
<ThatOSDeveloper> so bad news ... I did exactly that, I did it in this order eax
<ThatOSDeveloper> ecx
<ThatOSDeveloper> edx
<ThatOSDeveloper> ebx
<ThatOSDeveloper> ebp
<ThatOSDeveloper> esi
<ThatOSDeveloper> edi
<ThatOSDeveloper> and I still get the same number
<ThatOSDeveloper> just synced the commit
<ThatOSDeveloper> just had a quick update to it
troseman has quit [Quit: troseman]
<heat> i know, that's not the problem, but it is a problem
<ThatOSDeveloper> what in gods name does that mean?
<heat> its not the thing going fucky wucky
<heat> but it is a thing going fucky wucky
<ThatOSDeveloper> *screeches in confusion*
<ThatOSDeveloper> so in which ways is it wrong and which ways is it not?
<heat> you're missing push %esp now
<ThatOSDeveloper> oops
<ThatOSDeveloper> just added it in, still getting 1166609477
<heat> i'll be honest here i dont see what could be going wrong
<ThatOSDeveloper> me neither! this is certainly very fun
<heat> is your printk correct?
<ThatOSDeveloper> yeah
<heat> can you check with a debugger?
<ThatOSDeveloper> you mean run it thru a debugger?
<bslsk05> ​wiki.osdev.org: User:A22347/Printfure - OSDev Wiki
<ThatOSDeveloper> I mean I can run it thu a debugger
<ThatOSDeveloper> trying to rn
<ThatOSDeveloper> just got to my exception handler
<ThatOSDeveloper> I should go back and stop it at my exception handler macro
<heat> no, check the values there
<ThatOSDeveloper> like the int_num?
<heat> yes
<ThatOSDeveloper> for some reason it will not let me stop there I dunno I guess GDB does not like stepping at push instructions
<heat> there = C
<heat> do it in C
<ThatOSDeveloper> do it when I am in the C handler?
<ThatOSDeveloper> I tried, it will not let me look at its value
<ThatOSDeveloper> do I need to specify to look inside of the struct that is passed?
<heat> what?
<ThatOSDeveloper> like would I need to do print frame.int_num?
<ThatOSDeveloper> or something like that
<heat> frame->int_num
<ThatOSDeveloper> oh thx
<ThatOSDeveloper> so I do get (gdb) print frame->int_num
<ThatOSDeveloper> $1 = 0 but whenever I pass it it seems to fail.
<heat> ok, your printf is fucked
<heat> you're welcome.
<ThatOSDeveloper> perhaps, but then why does %d and such work everywhere else?
<ThatOSDeveloper> it does not seem to be fucked anywhere else and reports everything right everywhere else
<heat> i dont know
<ThatOSDeveloper> imma try something weird that might work
<ThatOSDeveloper> its not my printf
<ThatOSDeveloper> I just tried something independent of it
<ThatOSDeveloper> it seems to be my get_exception_message of all things
<ThatOSDeveloper> at least I think
<ThatOSDeveloper> no it cant be that
<heat> what exception message are you getting?
<ThatOSDeveloper> Unkown since get_exception_message does that when it gets a strange number
sbalmos has joined #osdev
<ThatOSDeveloper> I will use the debugger again to see exactly when it gets fucked up
<ThatOSDeveloper> strange right when I call get_exception_message it gets to 25 of all things instead of 0 which it is.
<ThatOSDeveloper> then it becomes 0 again
<ThatOSDeveloper> it stays 0 but for some reason fails as a Unknown exception
<ThatOSDeveloper> then out of nowhere it becomes 1779231875
<ThatOSDeveloper> I should try to back it up into another thing and try that instead
<geist> sometims that sort of thing is because your stack isn't aligned properly
<geist> i haven't read the entire backlog, but double check that
<ThatOSDeveloper> maybe? I dunno how would I check that
<geist> you should absolutely make sure it is to start, and then it'll probably not get out of aignment
<ThatOSDeveloper> but that would make no sense of it changing over functions if my stack was misaligned
<ThatOSDeveloper> and even if it was all my other functions should fail
<geist> it changing over functions?
<ThatOSDeveloper> more like lines, but yeah
<ThatOSDeveloper> goes from every number under the sun man
<geist> no it wouldn't. it tends to show up on printf because it's probably the only thing using varargs
<geist> and misaligned stacks tend to not show up until then
<geist> because the compiler will emit code based on that
<geist> depends on the arch of course
<ThatOSDeveloper> I did it in GDB, it changes, like from one function to the next, its 32bit
<geist> i didn't read the whole backlog but what arch are you on?
<ThatOSDeveloper> 32bit
<ThatOSDeveloper> i386
<ThatOSDeveloper> (I think)
<geist> mm, kk. you think?
solremn has joined #osdev
<ThatOSDeveloper> yeah its i386 (checked with makefile)
<geist> kk
remn has quit [Ping timeout: 260 seconds]
<ThatOSDeveloper> I get the same number, so at least the printk is consistant
<ThatOSDeveloper> its always 1166609477
<ThatOSDeveloper> welp, no solution in sight for me tonight
<ThatOSDeveloper> gn
ThatOSDeveloper has quit [Quit: WeeChat 4.5.1]
<heat> committed a buncha shit tonight!!
<zid> Both meanings?
<heat> probably
<sbalmos> did it clog your build pipelines?
<heat> yep
<heat> i have like 10 build jobs desperately building toolchains
troseman has joined #osdev
zhiayang has quit [Quit: oof.]
troseman has quit [Client Quit]
<geist> heat: you go girl!
<heat> yasss queeeen!!!
zhiayang has joined #osdev
<kof673> "Who's house? Run's house. Who's house? Run's house. Martin..." a 90s joke for the young ones
<kof673> *legacy joke
Halofreak1990 has joined #osdev
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
<heat> oh i finally got somewhat speedy tcp working
<heat> the problem ended up being that i wasn't recognizing that the remote host supported SACKing, and these higher bandwidth transfers routinely drop packets it seems
<heat> fixed that and went 500KB/s -> 5MB/s
dysthesis has quit [Remote host closed the connection]
guideX has quit [Remote host closed the connection]
cloudowind has quit [Ping timeout: 272 seconds]
guideX has joined #osdev
guideX has quit [Remote host closed the connection]
guideX has joined #osdev
heat has quit [Ping timeout: 264 seconds]
hwpplayer1 has joined #osdev
Halofreak1990 has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
McDonaldsWiFi has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Arthuria has quit [Remote host closed the connection]
PublicWiFi has joined #osdev
netbsduser` has quit [Ping timeout: 246 seconds]
goliath has joined #osdev
cloudowind has joined #osdev
kof673 has quit [Ping timeout: 240 seconds]
kof673 has joined #osdev
Lucretia has joined #osdev
guideX_ has joined #osdev
guideX has quit [Ping timeout: 252 seconds]
Halofreak1990 has joined #osdev
cppLover0 has joined #osdev
<cppLover0> hi
hwpplayer1 has quit [Read error: Connection reset by peer]
citrons has quit [Ping timeout: 252 seconds]
citrons has joined #osdev
GeDaMo has joined #osdev
Gordinator has joined #osdev
ryoskzypu has quit [Quit: ryoskzypu]
<geist> hola
ryoskzypu has joined #osdev
<ring0_starr> the hell was that guy about
<ring0_starr> how do you start writing your own os but you barely understand C and you can't read documentation
<ring0_starr> and more importantly, why are you helping him heat
<ring0_starr> way to encourage stupidity
<geist> because we're nice people
<geist> everyone starts off stupid. sometimes helping people actually works
cppLover0 has quit [Ping timeout: 245 seconds]
cppLover0 has joined #osdev
<Mutabah> For every 10 trolls, there's one misguided but enthusisastic person
<Mutabah> I know because I was one
craigo has joined #osdev
Halofreak1990 has quit [Ping timeout: 246 seconds]
frytaped has quit [Quit: WeeChat 4.4.2]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 248 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
solremn is now known as remn
<sortie> Well said. Most osdev journeys are 'try until you fail' and then the act of failing teaches you something valuable. Many people come back later, try again, and fail on something new and exciting. Some people fail so much they succeed in the end
craigo has quit [Quit: Leaving]
<GeDaMo> Success is just failing to fail :P
<nikolar> since when is this a philosophy channel
<nikolar> where are my language flame wars
<sortie> zid: Do not recommend passing a structure by value to newbies when writing interrupt handlers. Most people will push all the registers, run the handler, and then pop all of them. But that will corrupt your registers. Because under the System V ABI, the values on the stack belong to the called function, which may clobber the stack. This does happen. Passing a struct registers by pointer is the easiest way. The new OS in question here did in fact correctly
<sortie> pass it by pointer (see the push %esp int he code).
<sortie> This is a well known problem in one of the old tutorials that a lot of stuff ended up copying <https://wiki.osdev.org/James_Molloy%27s_Tutorial_Known_Bugs#Problem:_Interrupt_handlers_corrupt_interrupted_state> and then got this problem. So like, don't recommend that to people.
<bslsk05> ​wiki.osdev.org: James Molloy's Tutorial Known Bugs - OSDev Wiki
<sortie> (ok I see some of that code did change in the repo since then)
<sortie> nikolar: osdev is just applied philosophy
guideX_ is now known as guideX
bauen1 has quit [Ping timeout: 252 seconds]
edr has joined #osdev
stolen has joined #osdev
frytaped has joined #osdev
frytaped has quit [Quit: WeeChat 4.4.2]
getz- has joined #osdev
getz has quit [Ping timeout: 244 seconds]
frytaped has joined #osdev
bauen1 has joined #osdev
<kof673> philosophers were once considered dangerous, because they had the power to overthrow society -- messing with people's minds :D they were more dangerous than the flame wars, which was all talk :D
getz- is now known as getz
frytaped has quit [Ping timeout: 272 seconds]
Left_Turn has joined #osdev
frytaped has joined #osdev
hwpplayer1 has joined #osdev
q3lont has joined #osdev
sbalmos has quit [Quit: WeeChat 4.5.1]
goliath has quit [Quit: SIGSEGV]
Lucretia-backup has joined #osdev
Lucretia has quit [Ping timeout: 244 seconds]
Lucretia-backup is now known as Lucretia
bwani54 has joined #osdev
bwani54 has quit [Remote host closed the connection]
frytaped has quit [Quit: WeeChat 4.4.2]
sbalmos has joined #osdev
ebrasca has joined #osdev
Halofreak1990 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
frytaped has joined #osdev
cppLover0 has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 244 seconds]
heat has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
the_oz has joined #osdev
bauen1 has quit [Ping timeout: 265 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
Left_Turn has joined #osdev
gareppa has joined #osdev
Turn_Left has quit [Ping timeout: 265 seconds]
mrpops2ko has quit [Ping timeout: 246 seconds]
mrpops2ko_ has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
mrpops2ko_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
mrpops2ko has joined #osdev
gareppa has quit [Quit: WeeChat 4.3.1]
bauen1 has quit [Ping timeout: 244 seconds]
goliath has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
bauen1 has joined #osdev
sbalmos has quit [Quit: WeeChat 4.5.1]
goliath has quit [Quit: SIGSEGV]
m5zs7k_ has joined #osdev
sebastiencs4 has joined #osdev
sham1 has quit [Remote host closed the connection]
zhiayang has quit [Ping timeout: 248 seconds]
JTL has quit [Ping timeout: 248 seconds]
pog has quit [Ping timeout: 248 seconds]
mrpops2ko has quit [Remote host closed the connection]
deesix has quit [Ping timeout: 252 seconds]
zhiayang has joined #osdev
m5zs7k has quit [Read error: Connection reset by peer]
JerryXiao has quit [Ping timeout: 252 seconds]
sebastiencs has quit [Read error: Connection reset by peer]
sebastiencs4 is now known as sebastiencs
j`ey has quit [Ping timeout: 272 seconds]
mrpops2ko has joined #osdev
sham1 has joined #osdev
JerryXiao has joined #osdev
pog has joined #osdev
deesix has joined #osdev
j`ey has joined #osdev
leon has quit [Ping timeout: 245 seconds]
JTL has joined #osdev
Turn_Left has joined #osdev
leon has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
m5zs7k_ is now known as m5zs7k
heat has quit [Ping timeout: 246 seconds]
heat has joined #osdev
Halofreak1990 has quit [Ping timeout: 245 seconds]
sbalmos has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
sly has joined #osdev
xenos1984 has joined #osdev
sly has quit [Quit: Leaving]
bauen1 has quit [Ping timeout: 252 seconds]
Halofreak1990 has joined #osdev
cloudowind has quit [Ping timeout: 252 seconds]
cloudowind has joined #osdev
Rubikoid has quit [Ping timeout: 252 seconds]
Rubikoid has joined #osdev
netbsduser` has joined #osdev
q3lont has quit [Ping timeout: 252 seconds]
q3lont has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.9.1 - https://znc.in]
MiningMarsh has joined #osdev
d5k has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.9.1 - https://znc.in]
MiningMarsh has joined #osdev
q3lont has quit [Quit: Leaving]
d5k has quit [Remote host closed the connection]
m3a has quit [Ping timeout: 272 seconds]
m3a has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
<ring0_starr> sortie: but running into this issue and debugging it on your own is part of the test.
<ring0_starr> sure i get that it's not fair for a tutorial to contain the bug, but in order to "get so far" he's gotta have some kind of growing pain jeez
<ring0_starr> "i can't believe i got so far and i barely understand C and asm" he says
<cloudowind> kof673: its not the philosophers there its the questioning mind is found to be dangerous , what philosophers does is practicing this questioning , goodays people
<ring0_starr> he's got gdb up and running at least so there's a start, with just a bit less help and a few more pushes into the right direction he might've been able to eventually figure it out
<ring0_starr> in this tutorial on how to use a high level rust "crate", the language and lib itself changes so fast, the example code doesn't work at all, which as a rust beginner, makes me hate it as opposed to engaged
<ring0_starr> i'm not going to see this self-inflicted difficulty as an interesting hook to get me to learn deeper concepts when i haven't become invested into it at all
<ring0_starr> (self-inflicted as in, the thing i'm using created the difficulty, not me)
<\Test_User> if just the tutorial's example code breaks like that I'd hate to have to rewrite a whole kernel on the same time schedule
<ring0_starr> for an OS... i mean look, there are lots of OSes out there in the world today, some very successful and everywhere, but the thing is, these constructs he's playing with haven't changed in 40+ years
<ring0_starr> so there's this inherently difficult thing that isn't a constantly moving target and there are many inspirational high quality examples of what you could have should you succeed
<ring0_starr> that's far more motivational