channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=8&d=5
00:03:38 <ybyourmom> test
00:09:05 <zid> test failed, try again later
03:56:42 <squaremelon> in a nutshell the nutter has no friends , concepts like we while being pointed as a living dead body, is that filthy suicidal rats strategy, however one does not realize people who i have talked to say kamikaze boy is a major brainead nutter.
03:57:44 <Mutabah> squaremelon: Please, take that elsewhere
03:58:26 <zid> they're banned elsewhere
03:58:30 <zid> there's actual ops in some channels
03:58:43 <squaremelon> today was two shootings to follow the pattern of out conflicts
03:58:49 <squaremelon> our
03:59:34 <Mutabah> Well...strictly speaking he's banned here... but that was months and months ago
03:59:42 <zid> turns out, we're not responsible for people who don't take their antispychotic meds
03:59:57 <Mutabah> and he wasn't being abusive, so too much effort to re-ban
04:00:31 <zid> I ignored him the moment he first spoke recently and about 8 people have flashed the channel to tell him to shut up :/
04:00:33 <squaremelon> this kamikaze never gets a job again, he is constantly abusing people and talking about mental illness which is not allowed
04:00:46 <zid> like you can somehow reason with a potplant
04:01:17 <squaremelon> about two people in private chats have told me, that you are an absolute ratard
04:01:25 <Mutabah> and there it is
04:01:32 <zid> he's probably busy sending me paragraphs of text in privmsg like usual :P
04:01:44 <zid> asm had to ban .ee at one point :D
04:02:29 <Mutabah> He's used tor/VPNs here before
04:03:55 <zid> I asked him for the contact info for their carer but they wouldn't give me it, apparently the dragons in his teeth will stop me anyway
04:05:51 <aalm> knew it
04:06:22 <zid> aalm: when's finland invading estonia so we can finally put this to rest?
04:06:41 <aalm> hah
04:07:10 <aalm> you gave him the mentally ill-stamp, how could we
04:07:24 <zid> Pretty sure a fleet of doctors did that
04:08:01 <Mutabah> Sorry xenos1984, was waiting for him to join - so saw an estpak ipv6 address and booted
04:09:05 <xenos1984> No problem, Mutabah :)
04:09:17 <aalm> gpu
04:09:34 <aalm> just testing
04:10:17 <aalm> aww shithose
04:10:31 <Mutabah> Hmmm?
04:10:42 <aalm> mardestan pm'ing
04:11:28 <aalm> 07:11:05 mardestan | represent your name you shithose, and i will give you a decent beat up
04:11:58 <Mutabah> Just ignore him
04:12:15 <aalm> yep
04:15:32 <aalm> he's "mart martin" on fb, if you're looking for a new(old) friend :]
04:18:39 <xenos1984> zid: After Finland has been invaded by Russia (to answer your question from the logs). But if you know of any secret plans, let me know :D
04:39:22 <izabera> what do you guys think of immediate mode gui?
04:39:51 <izabera> as a paradigm, not any one specific implementation
04:48:34 <zid> no idea what that means
04:49:00 <zid> https://en.wikipedia.org/wiki/Immediate_Mode_GUI sounds like an 8 year old wrote it
04:49:03 <Mutabah> Iirc it's a GUI that's rendered with explicit rendering calls
04:49:22 <Mutabah> as opposed to one where the GUI is described by some data structure and re-drawn when needed
04:49:25 <zid> as in opengl immediate mode?
04:49:34 <Mutabah> think so
04:49:46 <zid> I've actually thought about some UI problems similar to this if it isn't this, at least
04:50:32 <zid> Everything sucks, I decided
04:50:38 <zid> Either things go stale, or you update things too often
04:55:27 <lkurusa> what's the supposed benefit?
04:55:36 <Mutabah> simpler
04:55:47 <Mutabah> hence easier to reason about
04:55:52 <lkurusa> I see
04:55:58 <Mutabah> but - it's less efficient, and doesn't scale very well
04:56:34 <zid> I was thinking mainly about EU4 at the time, I think, which is a game where you murder turks
04:56:51 <zid> but it tracks a lot of stats (like rpg stats), and they have to be recalculated.. sometimes
04:56:57 <zid> so I was thinkign about UI invalidation etc
04:57:16 <zid> and whether the UI should query the stat, or the stat should publish itself to the UI
04:57:59 <zid> And basically decided either you accidentally paint 'old' things because you threw it up into a texturebuffer, or you constantly recalculate the stats 60 times a second too many
04:59:12 * zid tangent
05:50:45 <graphitemaster> rerendering the ui many times per frame isn't an issue with good GPUs these days
05:51:05 <graphitemaster> immediate mode does not work well at all though if you plan on doing that
05:51:22 <graphitemaster> at least in my experience, since it ties logic up with rendering
05:51:33 <graphitemaster> it means all your logic now runs at the framerate too and that chugs things down
05:51:50 <graphitemaster> you want to limit logic at say 30fps, but render as fast as possible
05:51:59 <graphitemaster> which can only really be done with retained mode uis
17:44:22 <Ameisen> So, the FreeBSD build system requires the FreeBSD libc to be extant as it uses the headers to.. build libc
17:44:49 <Ameisen> that's lovely
17:45:42 <Ameisen> bmake is easy enough to acquire, but that's more difficult
17:46:49 <aalm> what are you up to?
18:52:04 <Ameisen> trying to build the freebsd kernel on not freebsd
18:55:19 <geist> for cross compiling like that you usually start by building a stage 1 compiler, then using that (with the freebsd libc) to start bootstrapping the next phases
18:55:34 <geist> so needing freebsd libc to build libc isn't really that odd
18:55:49 <geist> since you need the libc to build the cross compiler to build the full versions
18:57:57 <Ameisen> Problem is that to build freebsd's libc, it wants freebsd libc
18:58:06 <Ameisen> Which... I don't have, because I need to build it
18:58:16 <zid> bootstrapping is fun
18:58:32 <Ameisen> Trying to pull the headers out of the source into a separate include path for it.
18:59:02 <Ameisen> It doesn't need the implementation, just the symbols
19:01:16 <Ameisen> it's just annoying.
19:01:33 <Ameisen> There's no build target in their makefiles for bootstrapping freebsd-libc, so I sorta have to manually do so
19:01:49 <Ameisen> also, I really don't like their makefiles :|
19:02:08 <Ameisen> they're better than Linux', but still hard to follow
19:04:54 <heat> does anyone know if it's possible to set physical breakpoints in qemu?
19:05:01 <heat> so I can trap accesses to a physical page
19:51:53 <zagto> when I don't want to use the legacy PIC and mask all IRQs there, can I be sure I never get a spurious IRQ from the slave PIC because it is masked in master?
19:52:21 <bcos_> zagto: No. You can't stop the spuriousness
19:53:23 <zagto> meh, thanks
19:54:00 <bcos_> Hrm
19:54:48 <bcos_> Might be able to set master and slave to the same vectors; so both their spurious IRQs use the same interrupt vector
19:55:53 <bcos_> ..and never EOI the master when slave's spurious occurs
19:56:31 <Bitweasil> Couldn't you just unset the IF?
19:56:35 <Bitweasil> Not sure what you're trying to do exactly.
20:01:01 <bcos_> I'd have to dig through the chip's specs to determine if the special "cascade mode" cares about the mask or not; but we're not using the old "2 physically seperate discrete chips" anymore so it's likely far safer to consider it "undefined behaviour" (who knows how each different "everything integrated" chip will handle it)
20:02:41 <bcos_> ^ similar for tricks like telling master that the line is a normal IRQ and isn't "cascade mode" to make sure the mask works
20:07:40 <zagto> sounds like it's safer to just handle them both
21:38:30 <heat> that feeling when you spend days hunting for a memory corruption bug only to find out it doesn't exist and it was just a missing function call
21:38:47 <heat> I rate this experience 10 osdevs out of 10
21:39:50 <zid> I rate your debug capacity about 4/10 though :P
21:40:04 <heat> :P
21:40:15 <heat> to be fair I was debugging unreadable code that actually isn't mine
21:40:20 <zid> ah okay then
21:40:26 <zid> I'd have just used IDA at that point ;)
21:40:32 <zid> I trust compilers more than people
21:40:52 <heat> I honestly would trust IDA more than musl's coding style
21:40:55 <zid> god knows what crappy invariants they trick you into thinking are true when they're not if you read their comments
21:41:07 <zid> best to isolate yourself from code that looks correct but isn't
21:41:08 <heat> almost no comments and letter-named variables
21:41:14 <zid> start with incorrect code that's meaningless
21:41:18 <zid> and add your own naes and comments
21:41:54 <heat> but also, to be even fairer, I changed that function call like probably years ago for some random reason
21:42:14 <heat> I really don't know why because it doesn't even rely on things I don't have implemented *shrug*
21:42:22 <heat> past me was fucking weird
21:42:56 <zid> past you is an asshole who set you up for failure
21:42:58 <zid> you should beat him up
21:43:47 <heat> Florida man invents time travel just to beat himself up
21:44:34 <zid> It'd be sad if past you won
21:44:43 <heat> (and no i'm not from florida don't worry)
21:45:34 <heat> yeah that would be really sad
21:48:26 <xiphias> it's... the heat of the moment
21:49:01 <heat> ba dum tss
21:53:01 <geist> yah musl code quality is pretty icky
21:54:42 <heat> is it even possible to have a complete and fast libc without writing crap code?
21:54:55 <heat> somehow, someway they're all kinda bad
21:56:22 <zid> heat: nope
21:56:43 <zid> Anyone who is good enough to write a proper libc realizes that it isn't "bloat" it's the fact posix is fucking huge
21:56:47 <zid> and has a lot of things you need to resolve
21:56:58 <zid> so all the 'small' ones are just broken hacks
21:57:44 <heat> What?
21:57:56 <zid> small libc -> someone who thinks a real libc is 'bloated'
21:58:04 <heat> Posix isn't that big if you compare it to other system APIs like Win32/NT
21:58:24 <heat> no, small libcs have their place (embedded systems)
21:58:32 <zid> Right, and they often don't implement posix
21:58:39 <zid> the problem people have with specifically glibc is 'bloat'
21:58:50 <heat> well because glibc IS bloated
21:59:04 <zid> except posix is fucking *huge* and glibc covers a *lot* of platforms and use-cases
21:59:22 <zid> you'd sturggle to not end up with something like glibc if you end up with feature parity with glibc
21:59:36 <heat> well musl covers a lot of common use cases and it's very clearly not glibc
21:59:43 <heat> for the best and for the worst
21:59:55 <heat> at times it's even binary-compatible iirc
22:00:03 <geist> also posix and stdlibc tend to get all smashed together nowadays
22:00:13 <geist> Back in the Day you could try to keep them separate
22:00:41 <zid> yea you'd be really hard pressed to do that given that posix isn't a strict superset
22:00:46 <heat> geist: what do you mean with smashed together?
22:01:24 <zid> posix changes enough of C's behavior that you'd have to do everything dynamically
22:01:38 <geist> well, i that glibc provides a bunch of posix routines
22:01:55 <zid> it provides all of them
22:01:57 <geist> on more posixy unix systems many of them are mostly just wrappers around existing syscalls
22:02:14 <heat> well libcs do provide posix routines because they're more often than not the actual kernel API
22:02:17 <geist> but on systems that aren't really natively posix you need emulations
22:02:39 <geist> right, but technically that's not libc. libc should sit on top of another more low level library if that's the case
22:02:42 <heat> oh and isn't it specified by posix that -lc needs to bring up posix routines too?
22:02:46 <geist> even if the low level lib is basically just a list of syscalls
22:02:55 <zid> glibc contains a syscall passthrough version for every type of syscall version of that thing, and also a 'soft' version of that thing
22:03:05 <geist> but that's not how traditionally done in unix
22:03:08 <zid> because.. that's what you need :P
22:03:16 <geist> heat: may be, in which case that's basically where it goes wrong
22:03:19 <j`ey> Device-nGnRnE, wut
22:03:37 <geist> j`ey: check the arm manual, it describes what GRE bits mean
22:03:44 * heat checks
22:03:46 <geist> in that case it's not G not R not E
22:04:03 <zid> musl has weird things like setvbuf not working
22:04:10 <j`ey> Im going to a arm64 training tomorrow
22:04:16 <geist> woot
22:04:28 <geist> what those bits are are different properties of uncached memory
22:04:47 <geist> they each mean something, which is why there's like 16 different types of uncached, even if only about 2 or 3 of them are ever used
22:04:48 <j`ey> (although I guess it's going to be more application style stuff, than os/kernel stuff)
22:05:05 <geist> device-nGnRnE is the strongest form of uncached for 'device' memory
22:05:20 <geist> you'd use that to map a register, for example
22:06:04 <j`ey> Im reading http://infocenter.arm.com/help/topic/com.arm.doc.dai0527a/DAI0527A_baremetal_boot_code_for_ARMv8_A_processors.pdf
22:06:08 <j`ey> it has some MMU eamples
22:09:01 <heat> hmm I'm not completely sure but I think it's implied since POSIX is a superset of the standard C library
22:09:04 <j`ey> geist: about fsuchia, I guess that the kernel must be built with PIC/PIE so that it can be loaded/executed at any address?
22:10:10 <heat> not sure about fuchsia but in my kernels if I want to build them as relocatable I just tell the linker script to keep relocations, my bootloader passes them as a pointer and then the kernel just relocates
22:10:39 <j`ey> relocates itself?
22:10:44 <heat> and afaik that's how it works in linux as well
22:10:45 <heat> yes
22:10:46 <j`ey> heat: is yours open source?
22:10:51 <heat> yes
22:11:01 <j`ey> heat: is yours open source? and can I get a link?
22:11:15 <heat> note that it's x86 but the principle should be similar(just different relocations to perform)
22:11:28 <heat> https://github.com/heatd/Carbon/blob/master/kernel/arch/x86_64/relocation.c
22:11:56 <heat> then check the bootloader's elf loader and the linker script
22:12:07 <heat> (also, the Makefile)
22:12:35 <j`ey> neat
22:12:41 <j`ey> I will check it later, it's getting late
22:13:39 <geist> j`ey: yep
22:14:01 <geist> but remember that only affects where it is virtually located
22:14:12 <geist> you can build a non virtually relocatable kernel but make it physically relocatable
22:14:18 <geist> since that only affects the first little bit of code
22:14:27 <zid> mine is that
22:14:44 <heat> yeah right
22:14:47 <zid> I mean, it'd be a couple of lines to make it virtually relocatable too I just don't care :P
22:15:10 <heat> virtually relocatable kernels do have the advantage of being able to use KASLR and do things like spawn crash kernels and whatever
22:15:41 <heat> since I'm not working with arm I can easily just load wherever I want
22:16:19 <j`ey> virtualy relocatable seems cool too
22:16:27 <zid> my kernel's at -2GB cus why not, maybe at one point I will use a static pointer and I can movsx it :P
22:16:31 <j`ey> Im going to have to try get some page tables tomorrow
22:16:50 <heat> mostly you kinda want to aim for virtually and physically relocatable
22:17:01 <heat> for security and versatility purposes
22:18:45 <heat> re: POSIX
22:19:09 <j`ey> I read about this 'far jump', after you enable page tables on x86, I guess you need something similar on aarch64
22:19:44 <heat> I'm thinking about creating a custom "better" API for my second OS but I'm kinda thinking that I'm not google and I can't really port meaningful software that way
22:20:21 <geist> j`ey: sort of. you need to have an identity map before you branch up to it, yes
22:20:33 <heat> so I'll just be stuck writing software myself(which won't get nowhere fun)
22:23:27 <j`ey> geist: identity map -> enable mmu -> new kernel mapping -> jump to new virtual mapping -> remove identity?
22:24:03 <zid> You could probably delay that remove identity map until you create your init thread
22:24:37 <heat> no, it's probably like "identity map and new kernel mapping at the same time -> enable mmu -> jump -> remove the identity map and protect program segments ASAP"
22:25:55 <j`ey> ok, but close
22:26:43 <j`ey> also found https://witekio.com/blog/turning-arm-mmu-living-tell-tale-code/ to read