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
Burgundy has quit [Ping timeout: 252 seconds]
lainon has joined #osdev
<gog> that's sort of solving it by hand in a very roundabout way
nyah has quit [Ping timeout: 272 seconds]
dude12312414 has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 245 seconds]
gog has quit [Ping timeout: 272 seconds]
lainon has quit [Remote host closed the connection]
Coldberg has joined #osdev
C-Man has quit [Ping timeout: 256 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.4.1]
srjek has quit [Ping timeout: 240 seconds]
asocialblade has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 256 seconds]
rustyy has quit [Ping timeout: 252 seconds]
rustyy has joined #osdev
sprock has quit [Ping timeout: 256 seconds]
sprock has joined #osdev
mahmutov has joined #osdev
diamondbond has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
diamondbond has quit [Ping timeout: 272 seconds]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
diamondbond has joined #osdev
xenos1984 has quit [Quit: Leaving.]
diamondbond has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.4.1]
ThinkT510 has joined #osdev
the_lanetly_052 has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
Jari-- has quit [Ping timeout: 260 seconds]
the_lanetly_052 has quit [Ping timeout: 272 seconds]
mlombard has quit [Ping timeout: 240 seconds]
terminalpusher has joined #osdev
Coldberg has quit [Ping timeout: 260 seconds]
ThinkT510 has quit [Ping timeout: 260 seconds]
ThinkT510 has joined #osdev
C-Man has joined #osdev
gdd has quit [Ping timeout: 260 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
GeDaMo has joined #osdev
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #osdev
terminalpusher has quit [Remote host closed the connection]
nyah has joined #osdev
_xor has quit [Quit: WeeChat 3.4]
Burgundy has joined #osdev
gdd has joined #osdev
gog has joined #osdev
the_lanetly_052 has joined #osdev
<klange> Another clone spam on my os repo... what the heck is happening...
<nomagno> klange: what forge are you using?
albertobasaglia has joined #osdev
albertobasaglia has quit [Remote host closed the connection]
albertobasaglia has joined #osdev
<albertobasaglia> sad
<klange> forge? You mean like upstream hosting site? This is Github. I try, but generally fail, to keep things updated on a few sites.
albertobasaglia has quit [Client Quit]
<klange> Normally I see half a dozen clones a day on the traffic report, and most of those are automated tools like the CI pipeline.
<klange> On the 15th, and now again today, I'm seeing 700+.
<klange> And no increase in 'unique cloners', so it's probably one source clone hundreds of times for... who knows what reason.
<bauen1> ^ why would you even do that ?
<j`ey> stress test github :P
<nomagno> That doesn't seem like a huge issue
<nomagno> What if they're trying to simulate monkeys editing the project and see how close it gets to Hamlet?
<kingoffrance> one day you'll find some remote rainforest village, where they standardized on ponyos
<klange> this is the main repo, not the pony one, and they wouldn't need to make hundreds of git clones for that ;)
dude12312414 has joined #osdev
srjek has joined #osdev
CaCode_ has joined #osdev
<zid> debugging a build script and happening to be doing it against your repo
mahmutov has joined #osdev
CaCode_ has quit [Quit: Leaving]
arcadewise has joined #osdev
<arcadewise> Hi! Newbie here. I'm working through Meaty Skeleton, and I've run into an issue when trying to compile the kernel. Everything seems to be going good, then I hit this error: `/opt/homebrew/opt/i686-elf-binutils/bin/i686-elf-ld: cannot find -lk: No such file or directory`
<clever> what args did you run ld with?
<arcadewise> Well, it looks like it's running gcc, which is confusing, but here's what make says: `i686-elf-gcc --sysroot=/Users/arc/projects/stuttgart/meaty-skeleton/sysroot -isystem=/usr/include -T arch/i386/linker.ld -o myos.kernel -O2 -g -ffreestanding -Wall -Wextra arch/i386/crti.o arch/i386/crtbegin.o arch/i386/boot.o arch/i386/tty.o kernel/kernel.o -nostdlib -lgcc -lk arch/i386/crtend.o arch/i386/crtn.o `
<clever> you have a `-lk` in that arg list
<clever> that tells it to search for either libk.a or libk.so
<clever> and then link to that library
<clever> does such a file exist?
terminalpusher has joined #osdev
<arcadewise> Ohhh it looks like macOS is messing with me
C-Man has quit [Ping timeout: 256 seconds]
matrice64 has joined #osdev
rustyy has quit [Quit: leaving]
srjek has quit [Quit: Leaving]
terminalpusher has quit [Remote host closed the connection]
srjek has joined #osdev
gog has quit [Remote host closed the connection]
wolfshappen has quit [Quit: later]
gog has joined #osdev
wolfshappen has joined #osdev
<gog> mew
the_lanetly_052_ has joined #osdev
matrice64 has quit [Quit: Textual IRC Client: www.textualapp.com]
C-Man has joined #osdev
Burgundy has quit [Ping timeout: 260 seconds]
the_lanetly_052_ has quit [Remote host closed the connection]
the_lanetly_052 has quit [Remote host closed the connection]
asocialblade has quit [Changing host]
asocialblade has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<papaya> trying to migrate my kernel from 32-bit to 64-bit today, hoping I haven't bit off more than I can chew
<geist> you had written a lot of assembly right?
<geist> you'll have a lot of convert
<papaya> a fair amount
Burgundy has joined #osdev
<geist> though a fair amount of 32bit asm will generally work without modification on 64bit,but that actually is tricky because it seems deceptively simple
<geist> also your interrupt/exception code you'll have to redo from start, things like pusha dont exist on 64bit
<papaya> I've made enough modifications that it will at least compile and link tho now I cant find my multiboot header^^;
<geist> i'm all for it, but i'd like to nudge you in the direction of writing less assembly
<papaya> I know I manually changed it out for individual pushes of 64-bit regs
<geist> you *really* need to know the 64bit ABI too, which registers are saved/trashed and how args are passed
<geist> it's a lot more complicated than x86 32bit
<geist> print it oit and paste it on the wall, it's hard to remember offhand
<papaya> yea I assume the C calling conventions on x86 wont work here
<papaya> there's a lot more parameter passing via register I think?
<papaya> I did read about the red-zone issues with kernel space and I made sure to build my cross compiler to account for that
<geist> yep. first 6 args via registers now
<geist> and yep. red zone
<geist> you'll need to set -mno-red-zone when compiling kernel stuff
<papaya> but, grub2 should be able to find a multiboot header in a 64-bit elf file right?
<geist> also yay r8-r15! more regs
<papaya> yea its in my linker flags
<gog> grub can't use 64-bit elf's i think
<gog> although i may be remembering wrong
<papaya> I thought it was 64-bit elf aware just cant start long mode
<papaya> like I know the bootstrap code has to be 32-bit
<geist> right, grub wpnt directly load 64bit ELF i think, but you can still put in a multiboot header that loads it as if it was 32bit
<gog> idk for sure but i think so
<geist> and then it branches into it as 32bit
<geist> so you'll have to complete the trampoline to 64bit
<gog> honestly i'd recommend just using UEFI and writing a little ELF loader yourself
<gog> feel free to crib from mine
<papaya> the 32-bit bootstrap code is still inside the same elf binary tho is it not?
<papaya> gog: but you use efi and I'm not atm ^^;
<geist> if that;s how you want to do it, yes. that's how you do it
<gog> i mean you can do that
<papaya> geist: is it common to have separate 32-bit and 64-bit binaries for this
<geist> for exactly what?
<geist> (want to make sure i'm answering yes/no to the right thing)
<papaya> bootstrapping into longmode
<gog> you can have a shim in a 32-bit elf and the kernel loaded as agrub module
<geist> nah, it's generally easy to just have a little shim at the start
<papaya> thats what I thought, I kept BITS 32 in my boot file with the header and bootstrap (nasm)
<gog> i agree that it's easy but different things are different and should be in different files :p
<bslsk05> ​github.com: lk/start.S at master · littlekernel/lk · GitHub
<papaya> I'm building it into a single binary but now it doesnt find the multiboot header lol
<geist> multiboot header that points to a piece of code that trampolines into 64bit mode
<geist> yah i have two whole directories here, one for 32 one for 64
<geist> since it's pretty different at this level
<papaya> I think BITS 32 is the nasm equiv of gas .code32 ?
<geist> probably
<papaya> I just... really dislike att syntax
<geist> and at line 200 it switches to 64bit mode
<papaya> tho it seems a lot of ppl are using gas instead of nasm
<geist> the main annoyance with getting into 64bit is you have to use page tables to do it
<geist> since turning on paging is a requirement for long mode
<geist> that code just sets up an identity map of the first 64GB of physical space
<geist> with the assumption that the code is probably loaded there and thats enough to get into the kernel which will then set things up further
<papaya> I've done some tinkering with paging in 32-bit space
<geist> well, for better or worse you need to at least set up an identity map
asocialblade has quit []
Matt|home has quit [Ping timeout: 240 seconds]
<clever> that identity map also assumes that your 64bit entry-point is PIC
<geist> or you just link the kernel to run at a fixed address in physical
<geist> that's why i said 'at least'
<clever> assuming you know where ram will be
<clever> and can get the bootloader to load you to that addr
<geist> clever: we're talking about x86-pc here
<geist> different rules from what you may be used to
<clever> yeah, the whole upgrading from 32 to 64bits is backwards compared to arm
<geist> for what papaya is doing, you're literally telling multiboot where to load your binary, and thus you can rely on it being in a particular spot (or not loaded)
<clever> ahh, so you can be loaded to the addr you wanted, if that addr is ram
<papaya> btw you suggested I write less assembly but most my assembly is ISR or descriptor tables, etc... is it really a good idea to try to do these in C? what portions do you feel should or shouldn't be in asm?
<geist> right, and ram is implicitly starting at 0, etc
<geist> papaya: i disagree, most of your assembly seems to be things that can be written in C
<geist> like your keyboard driver, stuff dealing with a circular buffer, etc
<clever> isnt the first 64kb of ram kind of special though?
<clever> where bios keeps state
<geist> clever: yes.
<papaya> geist: so you think I'm doing too much in my ISR
<geist> there are places you dont tell multiboot to load to. generally avoid anything < 1MB, etc
<geist> papaya: yes.
<geist> more importantly you're writing the entire ISR in asm instead of a simple stub that gets you into C
<geist> where you write the meat of your ISR
<geist> usually systems just implement the register saving/restoring in asm, then branch to equivalent C (or whatever high level language you want) code
<geist> so that you end up with only hundreds of lines of asm in an entire OS, just the stuff you can't avoid doing in asm
<papaya> I was (perhaps wrongly) under the impression that doing anything in ISR with C was not a good idea
<geist> nope.not at all
<papaya> assume you mean nope as in I was mistaken
<geist> at the minimum you ant to take that pusha/etc stuff you have and make a macro out of it in asm so you dont have to type it in more than one
<geist> since it's extremely error prone
<papaya> I see, well now I know... should make things easier at the least
<geist> but see if yo uwrite the keyboard specific ISR code in C for example it would intrinsically work on x86-32 or x86-64
<geist> thus you only end up with arch-specific first level handler code, and that codes' job is to get registers saved and into a C environment
<geist> (note when i say C i mean 'C like languages')
<clever> what about how much the ISR asm should save?
<geist> it *does* mean you'll have to implement some inline assembly to wrap the in/out instructions so you can do that in C, but that's easy to do and there are tons of examples
<geist> clever: depends on the arch. extremely arch specific
<clever> do you prefer a full save/resotre of all registers? or save the minimal (abi clobbered) and let the function proloque's in c preserve the rest?
<geist> depends on the arch, for the most part. in general the latter, but the former may be just as simple, and easier to debug
<clever> in theory, both should work, if gcc correctly saves/restores the non-clobbered registers
<clever> exactly
<geist> depends on if there's actual real performance gains
ThinkT510 has quit [Ping timeout: 272 seconds]
<geist> arm64 LK i think still does the latter, but eventually we moved zircon to just doing the full save so it was a consistent iframe
<papaya> well I have in and out functions implemented in asm using C calling convention and exported to C
<geist> papaya: that works too, just make sure yo uget the calling convention right
<clever> the VPU LK port is doing a full save, because i'm sharing code between fatal exceptions and IRQ's
<papaya> I have it right, for 32-bit at least, obv will need to change it for 64
<clever> and the asm doesnt entirely know if the full frame is needed
<clever> but saving less is an option for improving performance
<geist> right
ThinkT510 has joined #osdev
ThinkT510 has quit [Read error: Connection reset by peer]
<geist> on something like riscv it's hard to know, since *all* exceptions and irqs come in via a single entry point
<geist> but arm64 for example at least has separate vectors for irq/fiq so you can save less there if you want
<clever> VPU is the reverse, every single exception and irq can have its own unique entry-point
<geist> x86 of course has 256 vectors so you can just macroize it to save different amounts if you want
<clever> and i'm just choosing to share one
<geist> yah that's what i'd recommend, pointing them all at the same routine
<geist> papaya will get to this soon too
<geist> the new intel FRED stuff if they ever implement it looks much more like arm/risc, iirc
<clever> with how LK does irq's, i couldnt really point the vector table directly into a registered handler
<geist> i think they collapse everything to one or a few entry points
<clever> because the optional reschedule at the end complicates matters
<geist> yep
<geist> arm cortex-m has that problem, and i have to resort to just requiring all implemented exception handlers *must* call this one routine at the exit
<geist> which does the schedule stuff
<clever> but that kind of changes the api for a lot of things, like timer callbacks
<geist> anyway, gotta go. visiting bay area this week, about to go visit the computer history museum
<geist> haven't been here in years, and it's now open again on weekends
<bslsk05> ​www.pcgamer.com: Retro computing museum in Ukraine destroyed by Russian bomb | PC Gamer
<clever> and another computer museum has been lost just recently
<geist> bummer. anyway, ttyl
<clever> yep
ThinkT510 has joined #osdev
<sham1> Inconsiderate jerks, nevermind the actual invading which already by itself is beyond mad
asocialblade has joined #osdev
<sham1> Bombing museums and museum planes and such. Eugh
cultpony has quit [Quit: ZNC 1.8.2 - https://znc.in]
cultpony has joined #osdev
rustyy has joined #osdev
Ali_A has joined #osdev
GeDaMo has quit [Remote host closed the connection]
immibis has quit [Ping timeout: 256 seconds]
immibis has joined #osdev
gxt has quit [Quit: WeeChat 3.4.1]
gxt has joined #osdev
Ali_A has quit [Quit: Connection closed]
joe9 has quit [Ping timeout: 256 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
heat has joined #osdev
<heat> HELLO
<heat> WHAT IS UP
<heat> just found out windows' storahci(ahci driver) has been entirely open sourced (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/miniports/storahci/src)
<bslsk05> ​github.com: Windows-driver-samples/storage/miniports/storahci/src at master · microsoft/Windows-driver-samples · GitHub
<heat> permissively licensed too
Matt|home has joined #osdev
Ali_A has joined #osdev
Jari-- has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 260 seconds]
the_lanetly_052 has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<sortie> <kingoffrance> i think you are supposed to write a client and join the sortie network
<sortie> <kingoffrance> and then success is when everyone in this channel has ascended to planet sortie
<sortie> ^ This is the canon ending to osdev.
<heat> >write a client
<sortie> Federation of Soverign Hobbyist ircds
<heat> nope
<kazinsal> brb starting a sortix-based networking appliance company called Sortinet
<sortie> Get Rich Quick® With Sortix
<heat> web3 sortix
<sortie> Sortix both has /tmp for your social media stories that expire and a libssl port for your scam needs
Ali_A has quit [Quit: Connection closed]
mahmutov has quit [Ping timeout: 260 seconds]
Jari-- has quit [Ping timeout: 240 seconds]
Jari-- has joined #osdev
<papaya> Think I figured out why my multiboot doesn't work with x86-64... the linker is literally padding the kernel by a full megabyte >.>
<heat> -z max-page-size=0x1000
<papaya> thanks
<heat> np
joe9 has joined #osdev
mahmutov has joined #osdev