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
SGautam has quit [Quit: Connection closed for inactivity]
simpl_e has joined #osdev
deflated8837 has quit [Ping timeout: 240 seconds]
netbsduser` has quit [Ping timeout: 245 seconds]
gog` has joined #osdev
gog has quit [Ping timeout: 260 seconds]
simpl_e has quit [Remote host closed the connection]
simpl_e has joined #osdev
deflated8837 has joined #osdev
deflated8837 has quit [Ping timeout: 240 seconds]
Maja has joined #osdev
ewwphoria has quit [Quit: Leaving]
m3a has joined #osdev
goliath has quit [Quit: SIGSEGV]
<geist> heat: oh was thinking of clrex
<geist> also riscv you're supposed to do an extraneous exclusive store to break any exclusive locks
<geist> not quite a barrier, but a context switching thing you're supposed to do to avoid a teensy little race
<heat> hmmm interesting
<geist> yup. that too
<geist> you need some sort of dsb in there
<bslsk05> ​fuchsia.googlesource.com: zircon/kernel/arch/arm64/thread.cc - fuchsia - Git at Google
<heat> i guess a release store will be some sort of dmb st vs dsb?
<geist> on arm there's explicitly a `clrex` instruction
<geist> on riscv i think it says to do an extraneous store to an unrelated cache line
<geist> i haven't done it yet on riscv, i have a todo to do that
<geist> i'll probably just write to a word in the percpu structure
<heat> btw i think you could do even without locks on x86 given iret is serializing?
<heat> right?
MiningMarsh has quit [Ping timeout: 245 seconds]
m3a has quit [Ping timeout: 246 seconds]
heat has quit [Quit: Client closed]
vdamewood has joined #osdev
SGautam has joined #osdev
Maja has quit [Remote host closed the connection]
<vdamewood> I think I want to put this into my kernel's source code: khang: jmp khang
<dh`> geist: iirc the store to bust ll/sc is only needed if you have a kernel so simpleminded that it manages to be able to interfere with a pending ll/sc without taking any of its own locks
<dh`> which is basically not a thing, so there's no reason to bother putting it in
vinc has joined #osdev
deflated8837 has joined #osdev
PapaFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
m3a has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
SGautam has quit [Quit: Connection closed for inactivity]
PapaFrog has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
LostFrog has quit [Read error: Connection reset by peer]
vinc has quit [Read error: Connection reset by peer]
PapaFrog has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
GeDaMo has joined #osdev
m3a has quit [Ping timeout: 246 seconds]
<geist> dh`: well, sure. you have to context switch between two things doing a ll/sc without any intervening ll/sc
<geist> but that depends on whether or not amoadds or whatnot also busts them, which iirc is not defined
<geist> so it's one of those *hypothetically* sort of situations
<geist> but yes it's highly improbable
[itchyjunk] has quit [Read error: Connection reset by peer]
<clever> geist: i got side-tracked, now that ext4 and usb 90% work, trying to play bad-apple now, lol
<geist> hah was just playing bad apple on my commander x16
<clever> one frame per .tga file!
<clever> then i just fs_open_file() every single file in one loop, that part seems cpu bound
<geist> hah cute
<clever> then i made a second loop, to just fs_read_file everything, and ignore the data
<clever> thats IO bound, and hasnt finished, after 5+ minutes
<clever> the ext2/4 driver doesnt merge requests
<clever> so its doing a full round-trip to the usb, for every 4kb block
<clever> but with ext4, you know ahead of time how big an extent is
<clever> so it could be optimized more
<clever> definitely too slow for realtime playback right now
<clever> but its only 248mb of tga files, i could buffer them, then decode in realtime, maybe
<clever> i also found your stats in bcache, and confirmed that going to 1024 blocks harms performance
<geist> mmhmm. nothing really caps off a saturday like someone complaining on IRC about some code you wrote like 15 years ago
<clever> not complaining
<clever> just off the top of my head, the cpu bottleneck in fs_open_file() is probably because i'm ignoring the ext4 dir hash tables
<clever> thats all my fault, because your code was ext2 only
<clever> thru the bcache stats, i found that at size=64, it had more misses then size=128, so it evicted things it needed
<clever> beyond 128, the miss rate never changed, and it only got slower with more size
<clever> so i was just increasing the size too much
<geist> that's probably it not having a proper hash table or something
<clever> yeah
<clever> both the ext and bcache are using linear searches
<clever> bcache records how many elements it compared against in the stats, so you can tell when thats becoming an issue
<geist> yup, just needs a hash table to speed that up
<clever> ext4 hides a hash table inside "deleted" file entries, but i havent implemented the hash algo
<clever> but, how often is bcache going to even be used on such a large cache?
<clever> i might actually flip things the other direction, use 2 bcache instances
<clever> one for metadata, one for data
<clever> then reading large files wont trash your metadata hitrate
<clever> the data cache can be small, if your reading the same file twice, thats your fault
<clever> but the metadata cache can be larger, since it would massively complicate the FS to cache every bit of metadata
<clever> now i feel like writing `top` or `perf top` for LK, all `threadload` says is 99% cpu
<clever> reading thread.c, i think a quantum is 10ms, and a thread gets 5 every time it runs out
<clever> and if it has ran out, it goes to the end of the run-queue
<clever> but nothing else about tracking per-thread usage
<clever> ] read all files in 2020881732 uSec
<clever> ah, it finished
<geist> threadstats
<clever> oh, nice, not sure how i missed that one
<clever> ah, but its not per-thread i think
<geist> yes it is
<clever> checking src...
<clever> and a distraction has come up, i'll read more later
<clever> geist: in the source, that is per-core, not per-thread
<clever> but will still be a good example of where to insert the counters
<geist> old source
<clever> ahhh, i'll have to rebase
<clever> rebased with zero conflicts! and now i see dump_threads_stats()!
<geist> not really top but it might get you what you want
<clever> but `perf top` is something your unlikely to have, would need symbols and all that jazz
<clever> and arch specific support for stack unwinding
<clever> so ive still got some fun i can do
<clever> platform/bcm28xx/platform.c:164:15: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
<clever> hexdump_ram((const volatile void*)addr, addr, len);
<clever> somehow, casting an uint32_t to a void*, is suddenly invalid, when it was valid before the rebase
<geist> probably some new warnings
Burgundy has joined #osdev
<clever> platform/bcm28xx/platform.c:131: Error: no such instruction: `version %esi'
<clever> geist: oh!, its because the cross-compiler stuff is broken
<clever> its using the wrong compiler, so void* is the wrong size
* geist nods
<clever> yep, NOECHO= reveals its using plain gcc, the host x86-64 gcc!
* geist nods
<clever> TOOLCHAIN_PREFIX = vc4-elf-
<clever> but it did print this during the build
<clever> maybe its respecting $CC suddenly?
<clever> yep!
<geist> it is
<clever> lk/lib/libc/atof.c:80: undefined reference to `__muldf3'
<clever> and something with libgcc.a has changed?
<geist> possibly whether or not it uses float or not
<geist> sdepends on how old your branch was before
<clever> float worked before the rebase, will need to investigate more
<geist> yes i changed some way float was done a while back
<clever> ah
<geist> added some new nofloat modules, etc. so i think your arch code needs to be moved up to date
<clever> ah, to tag it as having hw 32bit float
<geist> actually need to revisit it since it's not really ideal
<geist> but i forget the details and it's 1am on a saturday
<clever> i'll look at what arm32 does
<clever> go sleep!
<geist> well, no, i dont want to sleep i just dont want to tech support this right now
<geist> look throught he commits an dyou'll probably find what i did
<clever> yeah
<geist> the float stuff was done well over a year ago, so you have gotten fairly out of date
<clever> i see a new `MODULE_OPTIONS := float`
<clever> make/module.mk looks to have some logic that i should read closer...
<clever> ah, i see, that new flat allows the compiler to use hw floats
<clever> so you can make things interrupt safe, by doing softfloat elsewhere
<clever> 00000000 g F .text 000004a8 .hidden __muldf3
<clever> i do see the symbol within my libgcc.a
<clever> so i just need a -lgcc i think
<geist> you shoul dhave always had that
<clever> never needed it before, it might have been in one of your files
<sham1> You need it always when compiling with gcc
<clever> /home/clever/apps/rpi/lk-overlay/lk/lib/libc/eabi.c:35: multiple definition of `__dso_handle'
<clever> /nix/store/cwpy4q0qvdwdif1zfwnfg5gi50c6j9w8-vc4-elf-stage-final-gcc-debug-6.5.0/lib/gcc/vc4-elf/6.2.1/crtbegin.o:(.data+0x4): first defined here
<clever> i think the normal baremetal flags like nostdlib are missing, and its linking new things
<geist> dont link that
<geist> right
<clever> but i'm not sure why, git logs say it wasnt removed
<clever> will need to dig more after the distractions clear
<geist> resync your arch rules.mk. it probably got out of date via something changing
<clever> yeah
<clever> ive also noticed, linker gc breaks lib/fs
<clever> there is no KEEP on that section
<geist> feel free to actually roll changes back into mainline
<clever> yeah, i also need to finish my ext4 stuff and upstream that too
<clever> ah, arch/arm/rules.mk has some libgcc.a logic!
<clever> it seems it now wants an absolute path to libgcc.a
<geist> correct
<geist> not now, always has
<clever> ah
<clever> checked my git history, i was last on a commit from 2022-09-25
<clever> baca46e13344bec7adffcdc4e583288a86696b9a
<clever> now i can just pull up the diff, and read that closer
<geist> atof() was added in the interim, so it now needs libgcc that you never were providing before
<clever> i already had an strtof somewhere, and just had to add it to a .h file
<clever> looks like they basically do the same thing, but strtof seems better
<clever> ah wait a moment, its creating libc.mod.o, why is it even linking crtbegin then!?
<clever> thats only for the final link
<clever> (if at all)
<geist> its not at all
<geist> somethign is off in your arch
<geist> and/or one of CC/LD/etc is being overridden
<geist> but again i really dont want to provide tech support right now, can we put a pin in this?
<clever> ah yeah
<clever> i'm mostly just talking to myself, feel free to ignore me
<geist> i cant.
<clever> thats why i said to go to bed, you dont have to answer
<geist> it's intense nerd sniping
<clever> lol
<geist> like if i know you're talking about it i cant *not* drop what i'm doing to look
<clever> one last thing then, i had found a commented `LD := vc4-elf-gcc` in my arch file, uncommenting it broke libc.mod.o
<clever> re-commenting went back to the previous issue
<clever> something i'll need to investigate more
<geist> that's why. it' susing gcc to link it (vs ld) ad that's bringing in ctrbegin/etc
<geist> LK uses arch-ld to link explicitly
<clever> yep, forcing the -ld version worked
<clever> aha, link order again, -lgcc has to go after the usage, not before!
<clever> and LIBGCC does that,so i just need to populate it, like arm
<clever> it fully compiles and links!
<clever> it boots!
<clever> threadstats works!
vinc has joined #osdev
<ddevault> shell get https://l.sr.ht/mf4d.png
<clever> nice
<Ermine> Hello, Drew!
<sham1> poggers
<ddevault> hey Ermine
netbsduser` has joined #osdev
<mjg> __heat is ready to contribute to linux
vinc has quit [Read error: Connection reset by peer]
<GreaseMonkey> well, that was "fun", had screwy VGA output until i realised the CGA compat and Hercules compat flags in CRTC register 0x17 were supposed to be set to 1 to disable them
dennis95 has joined #osdev
vinc has joined #osdev
CaCode has joined #osdev
vinc has quit [Read error: Connection reset by peer]
zxrom has quit [Remote host closed the connection]
vinc has joined #osdev
vinc has quit [Read error: Connection reset by peer]
sortie has quit [Quit: Leaving]
netbsduser` has quit [Ping timeout: 246 seconds]
MiningMarsh has joined #osdev
<sham1> hi
osdev-guest has joined #osdev
<osdev-guest> Hi! Regarding RISC-V (using QEMU), is it better to use the linker script, which involves adding a heap region, or should I solely rely on the device tree for memory allocation?
gog has joined #osdev
vinc has joined #osdev
<zid> better for what?
<gog> meow
<zid> henlo
<osdev-guest> Better for a general purpose operating system.
<osdev-guest> The linker script approach is easier but comes with the problem of having a fixed amount of memory.
<zid> again, depends what you mean by better, just decide what you want
<zid> do you want to write it later, or now
<zid> 99% of the time these projects never ever get far enough that 'this will be useful in future' ever actually comes to pass
<zid> I wouldn't write anything that wasn't immediately useful
<osdev-guest> This is a fairly educational project
<osdev-guest> So maybe the linker approach is more appropriate in this case
<osdev-guest> But I was asking to know the general opinion about this, since some projects use the device tree
<Ermine> gog`: may I pet you
vinc has quit [Read error: Connection reset by peer]
<gog> yes
* Ermine peta gog
<Ermine> pets
gog` has quit [Quit: byee]
* gog prr
<mcrod> gog: hi
<mcrod> may I hug you
<gog> yyes
Left_Turn has joined #osdev
* mcrod hugs gog
* gog prr
<gog> hi barbie
osdev-guest has quit [Ping timeout: 246 seconds]
CaCode has quit [Quit: Leaving]
vinc has joined #osdev
Stary has quit [Quit: ZNC - http://znc.in]
CompanionCube has quit [Quit: ZNC - http://znc.in]
jjuran has quit [Ping timeout: 258 seconds]
vinc has quit [Read error: Connection reset by peer]
CompanionCube has joined #osdev
CompanionCube is now known as DrMushroom
heat has joined #osdev
vinc has joined #osdev
<heat> gog
<heat> baz
<gog> heat
<gog> foo bar bazinga
<heat> foozinga barzinga
<gog> now you're cookin with gas
vinc has quit [Ping timeout: 246 seconds]
vinc has joined #osdev
<heat> now you're cooking with nasm??
simpl_e has quit [Remote host closed the connection]
<heat> gog what's your favourite solaris version?
<zid> which version assembles with nasm
[itchyjunk] has joined #osdev
simpl_e has joined #osdev
<gog> heat: 420.69
<heat> haha funny weed number.sex number
<heat> you're most definitely cooking
<gog> haha
Stary has joined #osdev
<heat> gosh i really want to become a kernel
simpl_e has quit [Remote host closed the connection]
<heat> change my name to vmunix
<gog> unfortunately there's no HRT for that afaik
<zid> Is there HRT to make me a powerpuff girl
<gog> yes
<gog> sugar, spice and everything nice
<zid> Thanks, worked great
CompanionCube has joined #osdev
LostFrog has quit [Ping timeout: 240 seconds]
jjuran has joined #osdev
PapaFrog has joined #osdev
simpl_e has joined #osdev
PapaFrog has quit [Client Quit]
nyah has joined #osdev
<mcrod> i need to clean my room
<mcrod> i will pay someone $1 to do it for me
<gog> i'll do it
<zid> gog will keep anything found loose
<zid> she's like a squirrel but for usb-c cables
<gog> you can never have too many
<sham1> Everyone ought to be a squirrel for USB-C cables
PapaFrog has joined #osdev
antranigv has quit [Ping timeout: 246 seconds]
m3a has joined #osdev
zxrom has joined #osdev
dennis95 has quit [Quit: Leaving]
<heat> gog, my pronouns are now mm/page_alloc.c
<gog> congrats proud of you
<heat> i want to
<heat> iwan t to allocate pages
<gog> although it makes me cringe really hard when cis people make pronoun joeks ngl
<heat> :(
<heat> sorry
<gog> i know you're not doing it maliciously, but there's always that shadow of doubt
<gog> "am i being joked with or about"
<heat> yes i understand
<heat> won't happen again
<gog> not saying that you can't or shouldn't
<gog> just how it feels
<heat> it's hard to get a sense of what's a friendly joke and what's mocking on the interwebs
<heat> particularly through text
<gog> yeh
netbsduser` has joined #osdev
<heat> if only there was a way of communicating with people through text, voice and other forms of media
<heat> nah, that could cause some sort of discord
<sham1> Matrix!
<heat> everybody's gansta until matrix mofos post a fucked up link
<mjg> burp
<sham1> It's not broken if everyone's on Matrix
* sham1 taps head and nods
<mjg> bro are you even IN THE MATRIX
* Harriet uses IRC + Mumble
<mjg> i'm old schoool
<heat> it's really fucking ironic those dudes use the matrix as their WOKE macguffin
<heat> given that both the directors are trans and that the matrix has transness undertones
dutch has quit [Quit: WeeChat 4.0.2]
<froggey> taking the red pill (it's premarin)
FreeFull has joined #osdev
<gog> mmm horse estrogen
<heat> huh? horse?
<heat> "It is a mixture of the sodium salts of estrogen conjugates found in horses"
<heat> oh fuck lol
<heat> why tf would you use horses for this
<heat> kinda bizarre
<gog> the chemistry to synthesize it from plant sources wasn't known yet
<zid> horses are big
<zid> and mostly docile
<heat> how about hoomans tho?
<zid> cows are also used for stuff like this
<zid> and big pigs
<zid> humans are WAY more expensive than pigs
<gog> yeah you gotta pay humans
<heat> pigs deserve a fair wage too
<mjg> i had not seen fentanyl as red pills
<gog> which is (a very small part of) why some cancer drugs are outrageously expensive
<mjg> but i would take one
<zid> "Yea we're going to connect you to up to an IV for the next 10 years, you may feel like shit and grow boobs, here's $10"
<zid> "also we edited your genes"
<gog> because you gotta pay people something for their stem cells
<gog> and then the companies that make t hem need to recoup 200% of that cost
<gog> why 200%
<gog> ¯\_(ツ)_/¯
<zid> "and infected you with an e.coli that secretes gold, so we'll need to scrub your skeleton with a wire brush every 4 days"
<heat> 200%? too conservative
<heat> 1000% or bust
<zid> heat it's time for your brushing
<zid> open wide
<heat> i want to make a pharma company and mark up all my cancer medicine so i make $$$
<zid> too late
<heat> if i got something from the pope's speaches it's that young people need to make a difference
<heat> i want to measurably worsen everyone's lives, hence making a difference
<zid> grr my monitor is being really crashy rn
<heat> gpu toast?
<heat> or is your monitor really busted?
<zid> monitor
<zid> nurdrage has a synthesis series on making an expensive toxo/malaria drug
<zid> at home
<heat> How To Get In An FBI Watchlist
<zid> (pyrimethamine)
<zid> nilered had his 'making methlamine' video taken down, weirdly :p
<heat> what's methlamine?
<zid> precusor for making meth
<heat> (methylamine?)
<zid> yea
<zid> it adds the meth to methamphetamine
<heat> jesse
<zid> tasty stuff
<heat> we need to cook
<bslsk05> ​'jesse we need to cook' by Memetastic (00:00:07)
vinc has quit [Read error: Connection reset by peer]
Starfoxxes has joined #osdev
zxrom has quit [Ping timeout: 245 seconds]
dutch has joined #osdev
<mcrod> hi
<heat> hi
<mcrod> i have no humanity.
<heat> are you becoming hollow
<mcrod> yes
<heat> be safe friend. don't you dare go hollow
<bslsk05> ​'i live in a low income housing environment' by Physic snail (00:00:32)
Cindy is now known as bnchs
<zid> mcrod did you dark more soul
<heat> btw mcrod DLC?
<heat> u doing it this run or what
simpl_e has quit [Remote host closed the connection]
Harriet has left #osdev [not now]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
xenos1984 has quit [Ping timeout: 245 seconds]
xenos1984 has joined #osdev
<mcrod> i'll do it this run
<mcrod> zid: yes
<mcrod> but I _really_ need humanity
<zid> what for
xenos1984 has quit [Ping timeout: 246 seconds]
<heat_> summon solaris for the nito fight of course
<heat_> and then summon solaire
bnchs is now known as Cindy
zxrom has joined #osdev
<mcrod> no
<mcrod> i just need more than 5 estus
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
xenos1984 has joined #osdev
antranigv has joined #osdev
<heat_> mcrod, have you tried farming the baby skellies?
<heat_> they're your best bet
<heat_> careful tho, they're kinda dangerous
wblue has joined #osdev
<mcrod> no but I should try to farm them
<mcrod> also probably covetous gold
sortie has joined #osdev
Harriet has joined #osdev
CaCode has joined #osdev
<heat_> mjg, is freebsd + kasan zone allocation scalable?
<heat_> i assume not but i wanna make sure
<heat_> i'm quarantine'ing memory instead of sticking it on a pcpu free list and that takes a toll on my slab allocation
<heat_> i unfucked the slab allocation routines to drop the lock and that just... moved the contention point elsewhere (vmalloc does not scale)
<heat_> but i assume that at any memory allocation point i'll want to properly quarentine things
<mjg> i don't know, i would guess no
<mjg> whacking one bottleneck only to immediately run into another is the multicore life of a legacy codebase
<mjg> you are fucking up to be in this spote mate
<mjg> :X
<heat_> well, no
<Ermine> freebsd's memory management is legacy code?
<heat_> it's just hard to be super scalable while maintaining the KASAN properties you want
<heat_> (coherency, safety)
<mjg> you said your vmalloc does not scale?
<mjg> i assumed that's without kasan
<mjg> if memory serves you have top kek problems
<heat_> yes, but even if it did, i wouldn't want it to
<heat_> like, supposedly you want to put memory away for as long as possible
<heat_> and i don't see many ways of doing that without fucking scalability over
<heat_> if i switched things over to the page allocator i'd just switch the contention point to a page allocator zone
<sortie> heat_
<heat_> hi sortie
<Ermine> hey
<sortie> How're you?
<heat_> im fine thanks
<heat_> my stomach is way less fucked but now the heat wave is hitting and OH GOD THE CATHOLICS
<sortie> hi fine thanks I'm sortie
<heat_> how are you?
<sortie> I just got back home and did a festival on my birthday yesterday
<Ermine> We also have a lot of heat outside
<Ermine> happy birthday sortie!
<sortie> Yayyy thanks Ermine :D
<heat_> happy bday sortie!
<sortie> heat_, one of my fav bands wished me a happy bday and dedicated a song to me :D
<Ermine> That's sweet!
<sortie> Also hung out with another fav band that also wished me a happy bday and took a taxi homewards with the guitarist
<sortie> Fun :D
<Ermine> Super fun
<sortie> I'm feeling like doing some osdev
<sortie> It's time to patch GRUB
<heat_> ohno
<heat_> you're going from poggers to AHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<sortie> heat_: hmm=
<sortie> ?
<sortie> also beself
<Ermine> I'm feeling like doing osdev too
<Ermine> unfortunately it's late
<sortie> I did all of my best osdev at 2 AM
goliath has joined #osdev
<Ermine> I get enlighted at 4 AM
<netbsduser`> Ermine: by god, you're right, already 8 o clock
<netbsduser`> how in stinking crikey did it get to this time
<mjg> heat_: you don't non-kasan vmalloc to scale?
<Ermine> But if I go to bed late, my stomach goes crazy the next day
vinc has joined #osdev
<heat_> sortie, patching GRUB is pain
<heat_> in fact most linux distros are stuck in endless GRUB patching pain
<Ermine> Writing new bootloader is relatively poggers
<mjg> lmao
<mjg> this is why gentoo is the way to go
<mjg> you are too busy compiling in a loop to reboot
<sortie> heat_, ah it's fairly contained to configuration file stuff that is quite Sortix specific
<mjg> does mainline sortix do multicore now?
<mjg> how about some dragracing vs onyx
<mjg> :X
<heat_> mjg, btw, no. my vmalloc is kinda sucky atm. falls to the traditional mmap allocation problem (O(N) allocation), plus no pcpu caching nor lazy tlb flushing, etc
<sortie> mjg, just spin up two Sortix VMs :D
vinc has quit [Read error: Connection reset by peer]
<mjg> sortie: that's the openbsd solution :d
<Ermine> heat_: didn't you plan to implement rcu?
<heat_> yes
<heat_> Soon(tm)
<sortie> mjg: Mostly concerned about various important release and usability aspects at the moment, like making networked upgrading working, improving the packaging formats, fixing release blockers, making it possible to do better upgrades
<mjg> you seem user-experience focused
<mjg> what kind of dev does that
<heat_> lol i dont even have users
<heat_> the fuck is that
<mjg> ^^ there you go
<sortie> E.g. lots of distribution-level stuff that's really important and will lock my ability to change technical aspects incompatibly if I don't plan ahead
<mjg> who gives a fuck you can even'ti nstlal onyx, when it scales better?
<mjg> can't*
<mjg> you can install openbsd, but it scales worse
<mjg> so i'm not using it
<heat_> amen brotha
<heat_> there's no more uncomfortable question than "how do I install onyx?"
<mjg> i note again that obsd probably retains their totally fucked rw locks
<sortie> mjg, yeah one can install openbsd, but have you seen the upgrade process?
<heat_> the answer is: you don't, use windows
<mjg> and mutexes
<sortie> mjg: Serious rant here incoming
<mjg> oh?
<mjg> wait, you mean upgrade to another version or just patching
<mjg> bugs patching is supposedly easy, a 'la linux
<mjg> you do magic-command upgrade or similar and bam
<mjg> however, upgrading to another version is probably good old recompile by hand
<mjg> and then follow a readme
<mjg> to cleanstuff by hand
<Ermine> Is EFI_FILE_PROTOCOL buffered?
<mjg> sortie: waiting for the rant :]
<sortie> https://www.openbsd.org/faq/upgrade72.html ← Okay so here's an example, not the worst upgrade this one looks kinda okay, but see the section like "Files to remove"
<bslsk05> ​www.openbsd.org: OpenBSD Upgrade Guide: 7.1 to 7.2
<heat_> Ermine, no
<mjg> ye, that's how they were doing it for years man
<mjg> i'm very well aware
<mjg> :]
heat_ has quit [Remote host closed the connection]
<mjg> 21:16 < mjg> and then follow a readme
<mjg> 21:16 < mjg> to cleanstuff by hand
Lian has joined #osdev
<mjg> pretty lame, no?
<sortie> switch(4) and switchd(8) have been removed from the base system.
<sortie> To cleanup the user, group, and associated files execute the following commands:
<sortie> # userdel _switchd
<sortie> # groupdel _switchd
<sortie> # rm /etc/rc.d/switchd /usr/sbin/switchctl /usr/sbin/switchd /usr/share/man/man4/switch.4 /usr/share/man/man5/switchd.conf.5 /usr/share/man/man8/switchctl.8 /usr/share/man/man8/switchd.8
<mjg> you would think, if one is to execute this shite literally, why not add it to a fucking script or something
<mjg> and maybe ask the user if they want to do the action
<sortie> I mean they usually have a bunch of "oh, but special case, you also gotta do X" follow up steps to upgrades
<mjg> would be too user friendly
<mjg> interestingly, obsd users boast about the supposedly trivial insallation process
<sortie> Right an important context is that OpenBSD did inspire the Sortix install and upgrade process
<mjg> "hit enter a few times, done"
<mjg> wait what :d
<mjg> sorts
<sortie> But that upgrade process made me think "yeah I can totally do much better" (also with regards to installation btw)
<mjg> for me the quintessential install bit is they ask if i'm gonnna use X
<mjg> i say no
<mjg> then they propose a disk layout which has a /usr/X11 partition
<mjg> :d
<mjg> make sure to retain this step
<sortie> The Sortix upgrade backend is quite powerful and solves all of these problems automatically and transparently
<Ermine> they still put x11 stuff in a separate directory???
<zid> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff865248686, pid=28072, tid=29296
<zid> java ur dum
heat has joined #osdev
<Ermine> Ah, so I need to implement my own buffers around EFI_FILE_PROTOCOL
<mjg> here is a serious question sorts
<mjg> all this sounds like shit work one would do for a real project
<mjg> why even bother
<mjg> do you actually enjoy this?
<mcrod> do we even enjoy anything
<sortie> sysupgrade/sysmerge both use the /tix/manifest/* files for each port which contains a list of what files it contains, and then it compares the contents of the source and target filesystem, and it automatically removes all the files that no longer exists, even handling files that have moved to another port
<heat> here is a serious question heat
<heat> all this sounds like shit work one would do for a real project
<heat> why even bother
<zid> GC crashed
<heat> do you actually enjoy this?
<Ermine> You do
<Ermine> If you didn't enjoy this you wouldn't do this, right?
<sortie> sysupgrade/sysmerge also have a one-time upgrade hook mechanism, if the target system doesn't have a /share/sysmerge/foo marker file, then the upgrader runs a one time upgrade step that does things like convert configuration files to new formats and other rare migrations
<heat> i want mjg to understand it's a very stupid question
<heat> we do this for the love of the game
<sortie> sysupgrade/sysmerge also does things like update the initrd, reinstall the bootloader, all that stuff. It's all handled automatically. It also uninstalls ports that no longer exists.
<mjg> heat: i don't know anyone who likes installer work
<heat> sortie likes distro work
<heat> have you seen his ports collection?
<heat> all his *utilities*
<mjg> so you might have missed this bit
<sortie> mjg, basically all that bullshit from those upgrade guides, it's all automated and easy.
<mjg> 21:22 < mjg> do you actually enjoy this?
<mjg> sortie: i believe you, but why did you do it :]
<sortie> It's osdev, I do what I do :)
<heat> [20:23:30] <Ermine> If you didn't enjoy this you wouldn't do this, right?
<mjg> it's not how people work Ermine
<sortie> mjg, but seriously I did try every single Unix I could get my hand on and tried upgrading them, and honestly sooo many of them had shitty experiences
<mjg> what's your opinion on fbsd
<mjg> :)
<heat> it absolutely is
<mjg> and net
<Ermine> Also, apparently there are no readv/writev analogues in EFI_FILE_PROTOCOL
<heat> these are hobby projects
<sortie> DragonFlyBSD didn't even have an upgrade mechanism besides rebuilding from source
<heat> no one's paid for this
<mjg> sortie: netbsd has one?
<sortie> mjg, been a few too many years since fbsd and nbsd so won't comment on them :)
<mjg> i though they also build
<mjg> aight
<heat> Ermine: what are you doing/do you need any help?
<sortie> mjg, but honestly you know what inspires me to osdev? Whenever existing systems suck. It makes me feel "I can do better"
<sortie> So much Linux and BSD bullshit has inspired me for Sortix :)
<Lian> i feel like i dont even want to do osdev, i really just want to do WM/DE dev but that doesnt sound as cool
<Lian> X)
<sortie> mjg, as for the whole "why bother if there's no users", well you gotta build it before they come
SGautam has joined #osdev
<Ermine> heat: my plan for a prototype is to load a kernel from ESP and look for multiboot header
<sortie> I made Sortix 1.0 installable and upgradeable (more or less, some parts were delayed to 1.1, when I need it) and I made the promise that one can install Sortix and easily upgrade it to newer versions, so you know it's a safe and supported installation
<sortie> I'm definitely running around in circles around the other hobby osdev systems with how well I'm doing this
<Ermine> So i need to make a buffer for lookup process to not suck
<mjg> sortie: or you could fix the bullshit in the system
<mjg> sortie: so you expect actual users one day?
<sham1> Actual user might include sortie himself
<sortie> mjg, and yeah, I enjoy a job well done. A lot of the work has been making the install + upgrade implementation simple and powerful with a solid implementation that has great usability
<sortie> Well you know, I actually AM using this myself, big time. My websites run Sortix, I run an irc network on Sortix, even build Sortix on Sortix, even have a shared multiuser sortix server people can ssh into
<Lian> does sortix come with xfree86 or xorg?
<Ermine> Lian: it comes with display(1)
<sortie> Lian, the latest nightlies come with display(1), my own little GUI
<Lian> ooo fancy
DanDan has quit [Ping timeout: 245 seconds]
<sortie> mjg, but yeah I am actually planning for real users here, Sortix has become a quite useful server system actually. It's easy to install a server with things like sshd, nginx, whatever custom daemons you got.
<mjg> congrats mate
<mjg> i don't think there are many systems which got anywhere near real-world usability
<heat> Ermine: seeking around works
<sortie> Also yeah I am not really motivated to fix Linux & BSD bullshit that much, lots of it comes from compatibility constraints that they have decided to have, that I don't have to have
<heat> you could also just read it all to a big buffer
<heat> that's ok
<mjg> sortie: :D
<mjg> fuckin' tell me about it
<mjg> absolute nightmare on that front
<sortie> Yeah making a clean system without bad constraints is a big part of what I enjoy about Sortix
simpl_e has joined #osdev
gorgonical has joined #osdev
<gorgonical> Does anyone else think we should get hazard pay for working with bootloaders?
<gorgonical> I lose so much time to just the bootloader and firmware stuff, and the real kernel stuff takes maybe 1/4 the total work time when I'm fiddling with bootloader/firmware stuff
<mjg> sortie: but it still pretends to be unix?
<mjg> my main gripe is the shit APIs
<mjg> nothing can be done unless you reimplement everything yourself
<sortie> mjg, usually the problem is a few APIs that made life difficult across the system, and often I am able to drop them
<sortie> Things like putenv(3) is a problem because it leaks memory and it's unclear who owns it, so now setenv(3) and all the rest need to keep track of what variables are supposed to leak => complexity spreads because of one bad API
<heat> the gang implements FORK
<sortie> In Sortix, I've actively refused to implement a bunch of bad APIs, only providing the better versions that are usually widely available
<sortie> In a few places I've just invented some better APIs myself
<sortie> But generally I am actually happy enough with POSIX, just a few issues here and there that need to be improved
<sortie> Meanwhile I actually strive to implement POSIX and the key system calls really well with various technical qualities
<mjg> that is a manager statement
<mjg> openbsd has multicore support with varying quality
<sortie> I actually mean very specific things when I say that, there's a whole philosophy to how I do this stuff, mostly communicated it in chat, never wrote it all down together
<mjg> well i admire your resolve
<mjg> i'm a "get prototype working and ditch it" kind of guy
<mjg> productizing a solution is pain
<mjg> i mean all the error handling and idiot-proofing
<sortie> The thing that matters is what real ports actually do, whether I can actually get away with being different & better, you know, pick your battles
<mjg> you are either linux or it does not work
<mjg> or it predates dotcom bubble crash
<sortie> Truthfully ports are insatiable
<sortie> If you do all the stuff they want, it'll suck massively and might even be internally contradictory, or you must be Linux
<gog> hi
<sortie> (and even Linux is full of contradictions that distros have patched)
<gog> i'm bootloading
<sortie> But yeah, in Sortix I have the philosophy of patching port bullshit away (and upstreaming the patches) so they behave properly with the key qualities I require as a baseline
<zid> oh no
<mjg> "interestingly" existing ports trees like bsd ones or linux are full of absolute garbage
<zid> sortie: sort of like #ifdef LINUX feature1(); else featurea(); #ifdef LINUX feature2(); else featureb(); and featurea and featureb aren't actually a useful configuration?
<zid> I could totes see that happening
<gog> #ifdef CAT pet();
<sortie> Truthfully sometimes that's easier to patch than configure
<mjg> aah ./configure
<gog> autotools autotools autotools
<sortie> I am fluent in configure
<mjg> perhaps i should write a kernel comlpete enough to autounlink the file on execution
<sortie> I know nothing about m4
<gorgonical> maybe it's just me but honestly #ifdef PLAT_A feature() #endif makes me react violently
<gorgonical> something about it is just wrong
<sortie> But I can patch the fuck out of a configure script
<linkdd> hello there, i seem to have missed something in my understanding of the toolchain i'm using. I have clang v17 (for its support of c++23). for reference, here is my compilation options: https://bpa.st/SHTQ as you can see, i do have the `-ffreestanding`. I also refer to https://en.cppreference.com/w/cpp/freestanding in order to determine what headers I can use in the freestanding environment. It specifically
<bslsk05> ​bpa.st: View paste SHTQ
<bslsk05> ​en.cppreference.com: Freestanding and hosted implementations - cppreference.com
<linkdd> says that <atomic> is available since c++11. BUT, when I include that header, clang (v17) will include the following: https://bpa.st/NVEA however, the cstdlib header **should not** include stdlib.h in a freestanding environment.
<bslsk05> ​bpa.st: View paste NVEA
<linkdd> it seems that the __GLIBCXX_HOSTED is defined to 1 instead of 0
<linkdd> any ideas? or should i ask on the clang channel (if there is one?)
<sortie> This is a great place to ask about that, though I use gcc myself so I can't help with this question :)
<heat> linkdd: c++ freestanding is very incomplete
<heat> it's also buttfuck hard to get working correcly without hacks
<heat> clang and gcc <atomic> is not freestanding
<linkdd> ah so the standard says "yes it is" but the implementation is not there yet?
<bslsk05> ​github.com: Onyx/kernel/Makefile at master · heatd/Onyx · GitHub
<heat> linkdd: yes
<linkdd> when i read "since c++11" i though "well, they had 12 years to get it done, it should be okay" i was just naïve
<heat> haha
<heat> very few people use any of this crap
<heat> this is uncharted territory
<linkdd> yeay, i'm an explorer
<Cindy> hi #osdev
<Lian> hi cindy
<Cindy> i am sad because larry crane died on june 27th
<Ermine> heat: thank you for an idea
<heat> linkdd: btw -nostdinc and nostdinc++
<Ermine> Just reading file in a large buffer seems to be the right idea, since it's going to be loaded anyway
<heat> actually im not sure nostdinc is right
<heat> you may just want to set a sysroot
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat> just to not catch glibc headers while still getting the compiler stuff
<heat> Ermine: efi drivers have horrendous caching anyway
<heat> ext4dxe does no caching
<sortie> nostdinc is usually an antipattern, meaning you don't have a proper cross compiler setup
<linkdd> heat: -nostdinc -ibuiltininc ?
<heat> fatdxe has like 10 pages of cache
<sortie> You should pass some sort of option that makes clang actually cross compile, which means it does _not_ look in /
<heat> sortie: they'll always pick up whatever is defined as the sysroot
<heat> including /
<heat> it will also always look in / as the sysroot
<heat> unless you --sysroot=
<sortie> Yeah you always wanna --sysroot
<heat> relying on a pre-configured gcc sysroot is a bad idea as then you can't really... change your sysroot? sucks
<heat> and clang AFAIK does not have that anyway, so you always need --target --sysroot there
<heat> in fact for certain targets (like linux) clang will snoop around and attempt to find GCC installations
<heat> as a way to find libgcc :v
<sortie> I mean you can just --sysroot to change it
<heat> and libstdc++ of course
Lian has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<sortie> My top level Makefile injects the appropriate --sysroot
<linkdd> what is the appropriate sysroot?
<sortie> linkdd, wherever you place it
<heat> meaty skeleton!
<sortie> linkdd, https://wiki.osdev.org/Meaty_Skeleton is the tutorial I wrote about all of this, it's gcc centric though
<bslsk05> ​wiki.osdev.org: Meaty Skeleton - OSDev Wiki
<sortie> Building a cross gcc is a very well supported workflow in here that everyone knows about
<linkdd> yeah but i was like "hey, let's make it harder and use clang which is already a cross compiler"
<linkdd> thanks for the resources though
<sortie> clang can totally also be used, though unclear if anyone documented all of it, and whether it works as well as the documented gcc workflow that you can follow all the way until you even compile gcc on your own os
<linkdd> i'll look at it
<heat> both workflows are subtly broken
<sortie> "clang which is already a cross compiler" is a statement that is not quite true out of the box, you really need to still set it up properly
<heat> cross-gcc will have broken libgcc's on most archs (non-i686)
<sortie> Just using clang wrong is just as wrong as just using gcc
<heat> clang will not even have them at all
<linkdd> sortie: right
<netbsduser`> clang being an inherent cross compiler is of limited avail if your target is not of it
<netbsduser`> it has no x86_64-keyronex or m68k-keyronex targets so i would still have to built the thing
<sortie> linkdd, the details here are incredibly important, if your compiler is not actually a true cross-compiler, then lots of stuff can break in subtle and surprising ways that will fuck you up
<heat> netbsduser` even if it did you'd lack all the runtime libs
air has quit [Ping timeout: 258 seconds]
<sortie> Yeah what netbsduser` said, clang and gcc can't know about your OS down the road, you need to teach them about your OS and build them
<bslsk05> ​github.com: Onyx/kernel/lib/compiler-rt/builtins at master · heatd/Onyx · GitHub
<heat> (which actually works pretty well with both clang and gcc)
<heat> and accomodating all these differences is horrendous and time consuming and needs prior knowledge
<sortie> Meaty Skeleton is really one of the best things I've done
<sortie> Showing newcomers how to structure a new OS with a sysroot and proper cross compilation
heat42 has joined #osdev
heat42 is now known as heat69
<heat69> yeah meaty skeleton is pretty nice
<heat69> onyx still has some leftovers from that
<sortie> And how to provide a libc and libk
<heat69> oh it has .d support now
<heat69> sweet
heat has quit [Ping timeout: 246 seconds]
<heat69> "now"
<heat69> 2016-09-02 lmao
<linkdd> adding --target=x86_64-pc-none-elf makes the compiler unable to locate the builtin headers, like cstdint, or cstddef
<heat69> good
<heat69> you don't have those
<heat69> that's libc++ stuff you do not have
<heat69> welcome to hell pal
<sortie> Does <stdint.h> work?
<heat69> i believe it should
<sortie> gcc does provide that in the compiler itself when freestanding
<heat69> if they provide that, that is. i don't remember if they do
<sortie> stddef.h definitely
<sortie> Varies from platform to platform whether stdint.h is provided by gcc or libc
<sortie> In *-elf it's gcc
<linkdd> yes it does
<sortie> I don't trust those cfoo headers pretending to be <foo.h>
<linkdd> but if cstdint is not available, that means stuff like atomic, initializer_list, etc... won't be available as well
<heat69> the clang stdint.h, stddef.h, etc stuff is fully generic
heat has joined #osdev
<heat> my connection not being a piece of crap challenge [IMPOSSIBLE]
<heat> you can't use libc++ if you didn't build it for that arch
<heat> which you didnt
<heat> again, welcome to hell
<heat> toolchains are great and horrific
<heat> at some point you say screw it and do it all yourself
<heat> honestly, the more standard the worse
<sortie> heat, yeah sorry we went a technician to upgrade you to a professional Sortix network but you weren't available when we knocked
<linkdd> so i just have to build libc++ for my target, and link to it, right? :P
dutch has quit [Ping timeout: 260 seconds]
heat69 has quit [Ping timeout: 246 seconds]
<sortie> linkdd, 'just', note how cursed things can be if you want to link it into the kernel
<linkdd> sortie: yes, "just" was sarcastic
<sortie> linkdd, for instance, it may need to be built entirely differently with different compiler options
<heat> linkdd: your target doesn't support libc++
<heat> unless they have some barebones freestanding mode im not aware of
<sortie> For instance on x86_64, -mno-red-zone is needed for the kernel since the CPU interrupts will trash your stack (unless you use the ability to switch stacks on interrupts)
<heat> that may be the case, i havent worked with bare elf targets since forever
<linkdd> what is the point of "freestanding c++" if you can't target a freestanding environment...
<heat> its not, no one uses freestanding C++
<sortie> I had the worst bugs because my libk/libgcc wasn't built -mno-red-zone and I linked it into the kernel
<heat> or you take all your toolchain knowledge and cobble a bunch of shit hacks to make things work
<linkdd> sortie: i have this compiler option already
<heat> sortie: right, which is why most libgcc are subtly broken
<heat> + -mcmodel=kernel not being there
<sortie> linkdd, neato, just saying that if you build compiler libraries for use in your kernel, you will need a dual build of the kernel versions and the userland versions
<heat> and on other archs, fpu being enabled, etc etc (riscv doesnt even let you link)
<heat> IMO either don't use anything compiler related, or ship your own compiler-rt
<heat> the libgcc builtins part is pretty stable for each arch
<linkdd> sortie: well, my kernel library is statically linked into the kernel (.a), and it is built with the same cxxflags. it's just that i wanted to rely on some of the features that should be available in freestanding (like <atomic> and <initializer_list>, or <utility> for std::move / std::forward, ...)
<linkdd> but i guess i'll just have to write my own version of those headers
<linkdd> "just"
<sortie> Yeahhh
<heat> you can't
<sortie> You can probably import some code?
<heat> <initializer_list> is compiler-specific
<sortie> At least temporarily
<heat> <type_traits> is compiler-specific
<netbsduser`> i didn't used to rely on libgcc but now that i have an m68k port i do need it for 64-bit division and such
<linkdd> heat: yeah i know, concepts as well. so i need to make some sacrifices
<netbsduser`> and as for a lot of the C++ header files they have become freestanding in GCC 13 thanks to the efforts of veteran GCC hacker arsen
<linkdd> no --target=x86_64-pc-none-elf or no <type_traits> / <concepts> / <initializer_list> ?
<heat> you know <source_location>? believe it or not, very compiler specific
<heat> linkdd: -elf will let you make less mistakes
<heat> no one needs type_traits anyway
<linkdd> -elf or -gnu, the problem is -none-
<heat> no
<linkdd> heat: i do, i have my own templated containers, and i use concepts and such fancy features
<heat> that has nothing to do with anything
<heat> -elf is a bare metal target so x86_64-pc-none-elf is (for clang) the only valid combination there
<Arsen> i'm not sure veteran applies :P
<heat> \o/
<linkdd> heat: with -linux- it does find the c++ headers i want
<heat> -linux-elf?
<linkdd> complains about a missing features.h :)
<heat> i have no idea how thats supposed to be parsed
<heat> *shrug*
<heat> ofc
<heat> those headers are tailored towards glibc
<linkdd> -linux-gnu is my host system
<linkdd> so it would not make sense to just give it the same target triple
<Ermine> Seems like my spare adapter is dying. wpa_supplicant floods logs with CTRL-EVENT-SIGNAL-CHANGE ... noise=9999 ...
<linkdd> no, my trarget is x86_64-pc-none-elf, i need to build the toolchain for this target
<netbsduser`> Arsen: give it time
<heat> do consider if this is a battle you want to fight *right now*
<heat> because fighting the toolchain(s) is a very extensive, hard battle
<linkdd> i want <type_traits> and those compiler specific headers
<linkdd> i don't seem to have a choice
<heat> you can just... not want them
<linkdd> but i do want them
<Arsen> linkdd: --without-headers --disable-hosted-libstdcxx --without-newlib
<heat> this is clang
<Arsen> uninterested then :)
Gooberpatrol66 has quit [Quit: Leaving]
<heat> TIL --disable-hosted-libstdcxx though
<heat> or even without-newlib
<linkdd> TIL clang is a liar
<heat> i use --without-headers --with-newlib for a libc-less libgcc
<heat>     if [ "$enable_libc" = "no" ]; then
<heat>         libc_options="--without-headers --with-newlib --disable-shared --disable-threads"
<heat>         compiler_runtimes=""
<heat>     fi
Gooberpatrol66 has joined #osdev
vinc has joined #osdev
heat has quit [Quit: Client closed]
heat has joined #osdev
<heat> back on linux babyyyyyyyyyy
<sortie> psst
<sortie> Need Unix-like?
<heat> is it nordic?
<sortie> Is Finland nordic?
<heat> yes
<sortie> I found a finn to plot with against the Torvalds regime
<heat> i like the torvalds regime tho :(
<heat> its nice and comfy
* Ermine looks forward for his new wifi adapter
<sortie> It's all socialism and freedom under the Torvalds regime until you accidentally upload a kernel binary and don't wanna share the sources then it's jail time
<Arsen> heat: why with-newlib?
<heat> sortie, true socialism!
<heat> Arsen, --with-newlib makes libgcc go into no-libc mode
<Ermine> sortie: companies upload module binaries without source
<heat> For Some Reason
<Arsen> no that's not quite it
<sortie> https://wiki.osdev.org/Hosted_GCC_Cross-Compiler ← That newlib stuff is super weird, this is how to properly compile a libgcc for a hosted gcc cross compiler
<bslsk05> ​wiki.osdev.org: Hosted GCC Cross-Compiler - OSDev Wiki
<heat> well, this is not a hosted libgcc
<Ermine> I will never stop ranting about stock router firmwares sources
<heat> that would depend on a libc
<sortie> libgcc does need a few libc things like memcpy in principle
<heat> libgcc_s.so also links against libc.so :)
<heat> which doesn't help if libc links with libgcc
<sortie> But libgcc.a doesn't actually need to link with libc
<heat> also requires headers, etc
<sortie> Headers are a non-problem
<heat> so I build two toolchains
<sortie> You can just install those
<sortie> libgcc_s yeah is a future concern of mine, I'll figure it out when I do dynamic linking
<heat> stage 1 is a nolibc minimal gcc build, which builds musl, stage2 builds against musl
<heat> (stage2 includes clang too)
<heat> this is more or less the LFS approach too
<sortie> Ah, right, one thing I've done is to detach libstdc++ from gcc
<sortie> So I don't need two stages
<heat> stage 2 also includes libstdc++, libsanitizer
<sortie> I can just build the gcc and libgcc using only headers
<sortie> Then I can build libc
<sortie> And finally libstdc++
<heat> don't you get a slightly gimped libgcc in that case?
<sortie> libstdc++ as a forced part of gcc is so wrong and unuseful when bootstraping things in the right now
<sortie> heat, nah, libgcc just detects the features in the headers and use them
<gog> hi barbie
<sortie> And the cycle is resolved at link time when statically linking
<heat> yeah bbbut libgcc_s
<sortie> Can you do a no-actual-linking dynamic linking?
<sortie> Or maybe just generate a fake stub libc.so?
<heat> it may be possible to manually coerce the libgcc build into that
<sortie> Should be doable with a cross binutils that you already got that point
<sortie> Or maybe build libgcc_s in a follow up step?
<sortie> Or just always keep libgcc static? idk if the shared stuff is worth it
<heat> note that that can probably get hairily annoying if glibc (symbol versioning, slightly different ABI, ifuncs, etc)
<heat> idk if the shared stuff is worth it either
<sortie> libgcc_s.so will probably complicate the dynamic linker for libc.so itself
air has joined #osdev
<sortie> Since everything -> libgcc_s.so
<sortie> Including libc.so which makes it the non-root in the graph
<Arsen> libgcc and libc link eachother
<heat> libc.so is not guaranteed to be a root graph though
<sortie> Yeah I guess that's libgcc kinda, although actual cyclic
<heat> also: libc can't link libgcc dynamically im pretty sure
<sortie> Least with musl and Sortix libc, the libc binary contains all of the libc stuff including pthreads and rt
<sortie> (except Sortix still has libm)
<heat> glibc too now
<heat> except ld.so, that's still separate
<geist> maf is hard
<sortie> libc.so can totally link libgcc_s.so dynamically if do it yourself in your dynamic linker, question is whether you bother
<heat> no because libgcc_s.so will depend on libc.so
<heat> hence FUCK
<sortie> I'd probably be inspired by musl and make libc.so the dynamic linker
<heat> you get a cycle
<sortie> heat, well you load both and resolve the cycle
<sortie> If you bother and want to
<heat> hmm right
<Arsen> 23:12:10 <heat> also: libc can't link libgcc dynamically im pretty sure
<Arsen> it can
<Arsen> but i don't think anyone does actually
<heat> you're required to handle cycles?
<Arsen> so disregard that
<sortie> For Sortix, I'll probably stick with static libgcc (at least for libc) and then have libc.so contain everything and also be the dynamic linker
<sortie> heat, if you want cycles, yeah
<sortie> For big applications you'll probably have cycles too
<heat> well, it's not a wanting-situation. are you required to handle cycles by ELF and/or real world?
<sortie> I think so
<heat> i am honestly not sure
<heat> but if Arsen says so
<sortie> -lfoo -lbar can mutually depend on each other under shared linking
<Arsen> yeah that
<sortie> You can totally do cycles if the dynamic loader is it's own library
<sortie> *is its own executable
<heat> you can do them anyway
<sortie> If you make libc.so the dynamic linker though, then it needs to be runnable on its own without needing any dependencies
<sortie> That's probably the approach I will take
<heat> early ldso is super brittle as you're half-relocated
<heat> heck, you relocate yourself in the first place
<sortie> I need to read up on this stuff. For Sortix, I'd probably teach the kernel how to load a dynamically linked executable without dependencies, and then use that to load libc.so directly as the dynamic linker and libc in one go, and then use it to load the real executable and its dependencies
<sortie> Keep it simple and efficient with a hint of custom kernel support to make life easier and better
<heat> kernels just don't relocate things
<heat> relocation is annoying and hard to do from the kernel side
<sortie> It should be all position independent anyway, right?
<heat> except most of .data
<sortie> So the kernel can just mmap libc.so to a random address and run _start
<heat> sure, and traditionally PIE executables (ldso included) relocate themselves
<sortie> .data is a good question
<heat> also PLT stuff, GOT stuff
<heat> RELATIVE relocs are easy to do but... why bother from the kernel side?
<heat> then some new relocation pops up and your kernel is not up to date and spits your new exec out
<geist> side note: if you're using clang the 32bit rel-vtable thing we're using in fuchsia is pretty neat
<geist> really helps on the amount of rel updates you have to do with C++ code
<heat> is it stable enough for a default?
<geist> well, its ABI breaking so i wouldn't make it default
<geist> it's more of the platform default
<geist> or more to the point it's something a triple should opt into
<sortie> heat, at least I version the kernel and compiler together since I'm mono repo
<sortie> You bring up good points
<heat> doing things in the libc is hard and annoying but also makes sense
<heat> kernel should be simple
<heat> libc can crash all it wants
<sortie> heat, that's one area where we disagree
<sortie> Linux has the approach where the kernel does its thing and libc has to figure stuff out on its own without much help, and it doesn't work that well
<sortie> I have the approach where the kernel helps libc with the needed features such that the overall implementation is much simpler, safer, and faster
<heat> safer? im not too sure
<sortie> I'm unclear where that principle will lead me when I implement this, especially with the good points you bring up
<sortie> heat, yeah I have completely eliminated the weird early bootstrap phase in libc.a, all features are online already at _start including errno
<sortie> Not having weird early phases reduces complexity and potential bugs
<heat> reduces complexity in the libc for sure, but you pass it all to the kernel
<sortie> Nah like I said, reduces overall complexity
<heat> geist, btw does an arm64 booting in EL2 mean it supports KVM? or is there another requirement?
<Arsen> at the expense of safety in the far more critical component?
<sortie> Otherwise thread local storage in libc required opening the ELF executable to locate and map it as a bootstrap phase, but with kernel help (and it already parsed and loaded the executable), boom it's not needed and overall complexity goes down in this case
<sortie> And makes static linking even smaller
<geist> heat: on linux in general yes, but i remmber on rpi 3 or 4 there was the additional requirement that you've configured it to use the builtin arm time
<geist> timer, vs the broadcomm timer hardware
<geist> one of those boot.ini options or something
<geist> but in general aside frmo that case i think yes
<heat> i *may* have KVM on my rpi zero 2 w then
<heat> CompanionCube says his rpi3 has KVM
<heat> # CONFIG_VIRTUALIZATION is not set :/
<geist> yeah also depends on what distro you're runnig. i'm usually running ubuntu, which has all the bells enabled
<geist> raspbian probably does not enable it
<heat> im on alpine
<geist> probably even running in arm32 mode
<geist> oh dunno alpine, but yeah in general it should work, with the arm native timer the other exception
<geist> and 64bit kernel of course
<heat> the gang builds a new kernel
<geist> i default have and still do run kvm on my rpi4
<geist> so it certainly can
<geist> oh fun thing i read today: folks are finding rpi4s in abandoned scooters in Seattle
<geist> one of the scooter makers went out of biz and apparently left some hardware floating around, and each one has a rpi4, so folks are scavenging them
dutch has joined #osdev
* CompanionCube wonders if the ready-compiled kernels of https://github.com/raspberrypi/firmware include KVM
<bslsk05> ​raspberrypi/firmware - This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. (1672 forks/4867 stargazers)
<CompanionCube> looking at the modules.builtin shows 'kernel/arch/arm64/kvm/kvm.ko' so that's pres
xenos1984 has quit [Read error: Connection reset by peer]
<CompanionCube> so that's almost certainly a yes?
<geist> probably. easiest way to tell is via the presence of /dev/kvm
<geist> also like i said there was some sort of boot.txt or whatnot in the FAT partition that iirc you need to make sure it doesn't select the BCM timer
<geist> since KVM needs the built int arm-architectural timer to work properly
<geist> i dunno if that's still a thing, but it was at the time i was trying to enable my rpi4
* CompanionCube once used that repo's kernel to try out arm64 without reinstalling the whole OS, but i have lost that sdcard since
<geist> for some historical reason the rpi kernel seems to like using the BCM timer first, which is some external hardwar e(to the core) instead of the default one
<geist> i think it's for some sort of media playback reason
vinc has quit [Read error: Connection reset by peer]
* CompanionCube sees arch_timer/arch_sys_timer being used, but the irq for it in /proc/interrupts references bcm, so unsure which that is, since there's not another timer i can spot.
<heat> geist, knowing the BCM chipsets it probably releases radioactive isotopes every time you arm the ARM timer
xenos1984 has joined #osdev
<froggey> psci is the way to go for detecting/booting cpus on aarch64, right?
SGautam has quit [Quit: Connection closed for inactivity]
<linkdd> i ended up writing my own std::atomic, and not include the problematic header, leaving the problem of the toolchain for future me (i trust him, he's good)
<heat> froggey, yea
<heat> not sure about detecting (device tree tells you all that, no?) but certainly for booting em
<heat> linkdd, good choice
<heat> std::atomic is the least of your worries, it's just __atomic_* encapsulated
<heat> type_traits is fucked up as you depend on __builtins that aren't even documented
<linkdd> yes, and i'm not ready yet to give up on initializer_list, or type_traits
<gog> hi
<linkdd> at some point, i'll just git submodule the llvm project, and build the toolchain as part of my build system. i use cmake and they use it too, so the pain will be at choosing the right build options.
<linkdd> that's what SerenityOS does
<linkdd> they also have their own patches to add support for their target triple to llvm
Burgundy has quit [Ping timeout: 246 seconds]
<bslsk05> ​github.com: serenity/Toolchain at master · SerenityOS/serenity · GitHub
<Ermine> Lol, https://wiki.osdev.org/Loading_files_under_UEFI uses HandleProtocol while spec recommends OpenProtocol available since EFI 1.10
<bslsk05> ​wiki.osdev.org: Loading files under UEFI - OSDev Wiki
Maja has joined #osdev
<sortie> Well I said I would osdev so I messaged in here for a couple hours, procrastinated, and messaged a bunch of people on social media
<sortie> My work here is done
<linkdd> i'll procrastinate tomorrow
<geist> a win
<mcrod> hi
<mcrod> heat: I beat four kings
<heat> congrats
<heat> how about nito?
<mcrod> yes
<mcrod> now i'm off to seath the scaleless
<geist> all this rpi talk got me to open my rpi4 case *once again* and repair the fan
<geist> seems every few months the oil dries up and the sleeve fan starts to buzz
<geist> i should just fix that once and for all and get a good fan
<heat> how do you know its seath? are you following a tutorial?????!?!?
<mcrod> no
<mcrod> i googled
<mcrod> because it wasn't obvious where to go after I killed the four kings
<heat> good
<heat> you wouldn't want to know what i do to cheaters
<froggey> "qemu-system-aarch64 quit unexpectedly" this is fine
<sortie> aarch the screeeammmsss
<Ermine> I wonder if I want to make global variables ST and BS
<Ermine> for system table and boot services
<heat> yes
<heat> passing the system table around is annoying
<heat> tianocore code does that too
<heat> gBS and gST
<mcrod> you're fucking KIDDING ME
<mcrod> you're SUPPOSED TO DIE TO SEATH?
heat has quit [Remote host closed the connection]
heat has joined #osdev
SGautam has joined #osdev
<gog> efi is well-designed
<gog> i'm not though
<gog> i need a hug
* kazinsal hugs gog
* gog hug
Left_Turn has quit [Read error: Connection reset by peer]
<bl4ckb0ne> Ermine: global variables are baaaaaaaaaaad
<geist> but but if you put a g in front if it it's okay
<bl4ckb0ne> oh ok, carry on
<Ermine> bl4ckb0ne: yeeeees
<gog> it's not a global
<heat> damn globalists
<heat> fucking damn im fucked
<heat> building a new kernel is going to be depressing
<heat> 1) weak rpi with an sd card lmao 2) nfs share is slow as balls
<heat> ... i think this supports cross compilation
<geist> it's not too bad, just slow
<CompanionCube> if it's not too big, compile in tmpfs?
<gog> globalists are turnign the friggin variables gay
<heat> yeah its the linux kernel lol
<CompanionCube> ah, why not just yonik a prebuilt one from github or some other distro?
<heat> hard to integrate
<heat> i guess ill just build one manually from my laptop...
<heat> IF i can understand what the fuck is up with these patches
<CompanionCube> no more so than self-built kernels, i would think?
<geist> omg you are so whiny heat
<geist> just wait for it to compile, do something else while it compiles!
<geist> BACK IN MY DAY we had to wait a long time for stuff
<SGautam> I think I got the palette wrong but it works. https://usercontent.irccloud-cdn.com/file/owBWPCcm/image.png
heat has quit [Read error: Connection reset by peer]
<SGautam> We are officially xterm-256color
heat has joined #osdev
gxt has quit [Remote host closed the connection]
<geist> noice
gxt has joined #osdev
<heat> geist, hah
<heat> i understand your sentiment but this rpi really *is* slow
<heat> probably courtesy of the sd card, but the cores aint all that good either
<zid> heat yea but
<geist> rpi 3 i take it?
<heat> zero 2 w
<zid> if you die in the place you were born, your average velocity is zero
<geist> ah, hrm
<heat> it's half the size of a credit card :p
<geist> well, about the same guts as a rpi3
<geist> quad a53, etc
<geist> might have alot less ram though
<heat> 512M
<geist> yah that probably hurts its ability to cache the tree
<gog> back iny my day
<gog> we didnt' even have linux
<gog> or rather i didn't have linux, but my frame of reference is the only one that matters
<zid> gog: Had sweet steam paddleboats though
<heat> geist, fwiw 512M is plenty ok if you're not trying to do idk 4 core compilation
<geist> yeah that's what i was thinking
<heat> *and* your IO isn't dogshit
<heat> hence why I want KVM for it, for onyx
<geist> starts to push it when you have 4 instances running
<heat> without dealing with rpi peripheral fuckery
<geist> very wise
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat> the funny bit is when you realise it doesn't even have ethernet
<heat> so if you want to run your thing directly on it, you need a wireless stack
<heat> and fuck me am i not writing a wireless stack
<geist> yeah hell no
<gog> i will
<gog> gimme 5 minutes
<heat> ok
<gog> jk i won't
<gog> you're gullible
<heat> bruh
<mjg> would you contribute it to freebsd?
<mjg> if so, please write one
<mjg> SENKJU
<mjg> i'm going to take a piss, it better be ready when i get back
<heat> i tried to install netbsd on this but sadly wireless wasn't there
<heat> the rest worked tho
<heat> freebsd was much further away from working
<heat> mjg, wanna see some flamegraphs i took today?
<mjg> how much of it cpu_relax
<gog> where did you take your piss, to a nice dinner date? a movie?
<gog> also why does one take a piss but have a shit
<mjg> you have to take to give
<heat> mjg, lots of spinny but at different points
<mjg> :[
wblue has quit [Quit: wblue]
<bslsk05> ​gist.github.com: stackdepot1.svg · GitHub
<heat> all KASAN fgs
<heat> 1 is the starting point, lots of contention in the slab_cache->lock
<heat> 2 i unfucked some of the pcpu magazine refill to drop the lock when allocating, contention moves to vmalloc
<heat> 3 i removed the quarantine for kmalloc
<heat> 4 removed the quarantine for all
<heat> originally this was to measure stackdepot's contention in a alloc-heavy test (mmap1_processes)
<mjg> why is this contending?
<heat> what is "this"
FreeFull has quit []
<mjg> any of this really
gog has quit [Ping timeout: 246 seconds]
<mjg> if have not looked into this, but i strongly suspect this can be made to mostly scale
<mjg> virtually all the overhead should be single-threaded
<heat> quarantine needs a global lock eventually
<mjg> for what
<heat> i have a "small" (16MiB atm) percpu quarantine that feeds back into a big quarantine (256MiB)
<heat> that big quarantine then frees objects once it overflows
<heat> problem with quarantining everything is that nothing feeds back into the pcpu magazine anymore
[itchyjunk] has quit [Ping timeout: 260 seconds]
<heat> for completeness' sake, my lock avoiding patch: https://gist.github.com/heatd/deb7808eb1f1ed5010ae60dfdadc6688
<bslsk05> ​gist.github.com: slab.patch · GitHub
<mjg> maybe you can get some ideas from openbsd
<heat> problem: my vmalloc does not scale
<mjg> maybe you can get some ideas from openbsd
<heat> problem2: ideally it'd get its own quarantine? i don't know
<heat> problem3: i could use the page allocator but, again, nothing would feed back into the pcpu lists. but there would be a large win from having some in the first place, i assume
* mjg burps
<mjg> have you tried running trinity yet
<mjg> or are you going striaght for syzkaller
<heat> why I don't use the page allocator + direct map directly: i had perf regressions from using the direct map, and it doesn't support KASAN yet
<heat> i have not thought about that for a long time
<mjg> maybe run the ltp suite
[itchyjunk] has joined #osdev
<mjg> it wont work, but the q is if your kernel will panic
<heat> will probably finish my local work, go for RCU, then either arm64 or basic read/write stability
<heat> as soon as I have that, it's pretty usable
<heat> it just needs a good rework on dirty/writeback paths
<mjg> lol check out this mofo + REQUIRES(mm->vm_lock)
<mjg> faken' locking annotations
<mjg> you are better than linux for the most part
gog has joined #osdev
<zid> glorg, spawn of the underlords, has returned!
<zid> What a blessed day!