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.