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
radens has joined #osdev
<radens> Hello. I'm having trouble getting the timer interrupt to work on qemu emulating an rpi3 (BCM2837, a quad core 64 bit arm machine)
phy1729 has left #osdev [#osdev]
<radens> If I understand correctly I need to: 0. Set VBAR_EL1 to my vector table. 1. enable the timer IRQ in the INTERRUPT_BASIC_ENABLE register in the interrupt controller by setting bit 0, 2. Enable the arm architectural timer by setting bit 0 in CNTP_CTL_EL0. 3. Set the deadline/count down register to a value larger than the timer physical count value. This can be done by a. punching a number into CNTP_TVAL_EL0, or b. setting CNTP_CVAL_EL0
<radens> to be a value greater than the physical timer value. 4. Do wfi to wait for an interrupt and the timer to expire.
<radens> Oh also doing msr daifrclr, #2 to clear the interrupts mask
<clever> radens: you could try enabling the uart irq first, to confirm most of the other irq stuff is working?
<radens> I'm doing all of that but the IRQ isn't triggering
<radens> clever: yeah I could program the UART instead, but I figured I'd ask here first in case I'm missing something obvious
<_eryjus> radens: I remember having trouble with the rpi2b and the solution was far simpler than I expected. looking for an example if that will help
<radens> _eryjus: thanks
tacco has quit [Remote host closed the connection]
<bslsk05> ​github.com: century-os/TimerInit.cc at master · eryjus/century-os · GitHub
<_eryjus> disclaimer: I have not yet worked on a pi3.
<zid> quaqpoople check you got the right number of 0s in all your defines :p
vai has joined #osdev
<vai> hi morning everyone !
<_eryjus> radens: here is the PIC setup for routing the IRQ as well: https://github.com/eryjus/century-os/blob/master/platform/bcm2836/pic/PicInit.cc#L23
<bslsk05> ​github.com: century-os/PicInit.cc at master · eryjus/century-os · GitHub
<vai> Does IDE0, IDE1, etc. or SATA0, SATA1 respectfully - support simultaneous access on all hardware available in the markets?
<vai> Is copying from IDE0 to IDE1, reading sametime as wriiting supported, or is it just mym Qemu/VirtualBox emulated hardware supporting this?
<vai> E.g. might at least some interrupt violations, have to share, etc. Very dirty!
<vai> morning from Finland :-)
<Affliction> with IDE, devices on the same cable can't communicate simultaneously, if you have two channels, they're independent. SATA ports are independent, and most vaguely modern drives support command queuing.
<Affliction> With interrupts, either way you have to ask the controller about why the interrupt was raised, so you can establish which disk caused it.
Belxjander has quit [Quit: AmigaOS PPC 4.1 +E +U1 // AmIRC 68K]
<zid> one last random thought, clear out any pending irqs? maybe it was edge triggered and you missed it while it was masked at boot
eryjus has joined #osdev
<clever> zid: i think the timer irqs are level triggered, when i didnt mask every interrupt in my bootloader, it causes linux to just deadlock
<zid> shame
<clever> because linux wasnt expecting the timer to be in that mode, and when the irq's got enabled, it immediately got stuck in a loop for an irq it wasnt prepared for
_eryjus has quit [Ping timeout: 268 seconds]
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 260 seconds]
eryjus has joined #osdev
_eryjus has quit [Ping timeout: 264 seconds]
Belxjander has joined #osdev
mctpyt has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas has joined #osdev
ElectronApps has joined #osdev
vdamewood has joined #osdev
gog has quit [Ping timeout: 264 seconds]
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 245 seconds]
[_] has joined #osdev
_eryjus is now known as eryjus
[itchyjunk] has quit [Ping timeout: 264 seconds]
radens has quit [Quit: Connection closed for inactivity]
<eryjus> klange you around?
skipwich has quit [Read error: Connection reset by peer]
vdamewood has quit [Ping timeout: 245 seconds]
vinleod has joined #osdev
srjek|home has quit [Ping timeout: 264 seconds]
[_] is now known as [itchyjunk]
Oli has quit [Quit: leaving]
Oli has joined #osdev
<klange> eryjus: 'sup?
vinleod is now known as vdamewood
Oli has quit [Quit: leaving]
<klange> I think I will do one more beta for November, 1.99.9, and 2.0's final release will be holiday gift.
radens has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
C-Man has quit [Ping timeout: 264 seconds]
GeDaMo has joined #osdev
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 260 seconds]
ravan has quit [Remote host closed the connection]
radens has quit [Quit: Connection closed for inactivity]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
m3a has quit [Quit: leaving]
myon98 has quit [Quit: Bouncer maintainance...]
Oli has joined #osdev
Sos has joined #osdev
myon98 has joined #osdev
gxt_ is now known as gxt
[itchyjunk] has joined #osdev
[_] has joined #osdev
[_] has quit [Client Quit]
srjek|home has joined #osdev
pretty_dumm_guy has joined #osdev
<klange> Now this... is something I've wanted to bring back for ages. https://klange.dev/s/Screenshot%20from%202021-10-31%2022-22-48.png
<Mutabah> alt-tab window previews?
<graphitemaster> > The requested URL was not found on this server.
<klange> My original compositor - the one before Yutani - had a window switcher that showed the window texture. With Yutani, the window switcher was moved to the panel and it lost that.
<klange> graphitemaster: Check that your IRC client isn't incorrectly double-encoding %'s or something silly.
<graphitemaster> IT seems to be lol, it generated: https://klange.dev/s/Screenshot%2520from%25202021-10-31%252022-22-48.png when I clicked on it
<bslsk05> ​klange.dev: 404 Not Found
<graphitemaster> Good job HexChat
<klange> Discord had a similar issue in their iOS app.
<graphitemaster> I find it interesting that URL encoding and decoding is still a problem.
<graphitemaster> I remember Chromium had a serious bug where it would get stuck in an infinite loop or something not long ago.
<klange> There will always be someone around to screw up double encoding or decoding.
<graphitemaster> We'
<klange> Let's add the icon back in, like Gnome et al do: https://klange.dev/s/Screenshot%20from%202021-10-31%2022-31-42.png
<graphitemaster> We're doomed to repeat bugs
<graphitemaster> ToaruOS already better than Windows 11 because you can put your taskbar at the top
<klange> Funny you say that since there's still a silly quirk in the compositor where the way it maximizes / tiles windows is entirely based on the bottom edge of the "top z" window (if one exists), so it can _only_ be at the top.
<klange> No reason I can't make that logic a bit smarter, of course - the real blocker for the panel being elsehwere is the menus that currently open down.
<klange> Anyway, while I had to tweak some of the protocol for Yutani, this isn't really doing anything special, it's just the panel taking window buffer IDs and quietly mapping them to use as a texture source. The only thing I had to change was telling the panel those buffer IDs... and the sizes of the windows.
srjek|home has quit [Ping timeout: 245 seconds]
<klange> Previously it just got window ID, some flag bits (focused, etc.), and the title/icon name.
srjek has joined #osdev
<sortie> klange, sweet alt tab view
dennis95 has joined #osdev
gog has joined #osdev
<zid> klange: I take it you implemented the full jpeg spec and all existing out of spec variants now?
m3a has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 260 seconds]
sonny has joined #osdev
tacco has joined #osdev
kpel has joined #osdev
sonny has quit [Ping timeout: 260 seconds]
sonny has joined #osdev
Electron has quit [Remote host closed the connection]
C-Man has joined #osdev
sonny has quit [Quit: Going offline, see ya! (www.adiirc.com)]
tacco has quit [Remote host closed the connection]
tacco has joined #osdev
kingoffrance has joined #osdev
dude12312414 has joined #osdev
lleo has joined #osdev
eryjus has joined #osdev
_eryjus has quit [Ping timeout: 260 seconds]
dennis95 has quit [Quit: Leaving]
mahmutov has joined #osdev
lleo has quit [Ping timeout: 264 seconds]
<jeaye> klange: You're on HN.
<junon> link?
<junon> oh shit #3
<bslsk05> ​news.ycombinator.com: A completely-from-scratch hobby operating system | Hacker News
<junon> Already, "why didn't he write it in Rust?"
<junon> >.>
<zid> because ycombinator is a website
<zid> ergo it's full of children and idiots
<j`ey> junon: you left out the context :P
<zid> the context is "why not rust"
<junon> huh?
<j`ey> no the context why 'why did he make it posix and monolithic'
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
<Ameisen_> "why didn't he write it in Rust", but no "why didn't he write it in C++".
<Ameisen_> Blasphemy.
<Ermine> And 'Why not microkernel?'
<gog> why didn't he write a new language to write it in
<junon> 0/10 doesn't run on 6502
<junon> ridiculous in 2021 people make OSes that don't run on 6502
hzshang has joined #osdev
<sortie> https://wiki.osdev.org/User:Sortie/Yes_Another_Unix_Clone ← I wrote this rant last time I was on the news hacker
<bslsk05> ​wiki.osdev.org: User:Sortie/Yes Another Unix Clone - OSDev Wiki
<MelMalik> junon: nobody uses 6502
<jeaye> sortie: I agree with your sentiment. I think that your "innovation" section ends with a contradiction, though.
<eryjus> sortie: people who can't criticize those who can
<jeaye> sortie: "A custom design should at least be an order magnitude better than POSIX to be worthwhile." contradicts your previous point that people can build whatever they want.
<jeaye> Just building it makes it worthwhile.
mahmutov has quit [Ping timeout: 260 seconds]
<jeaye> Since there is not objective "worthwhile".
<sortie> I am not telling people to do anything worthwhile :)
<zid> Nothing's stopping anybody supporting.. two APIs
<zid> windows also supports a subset of posix, and you know, WSL
<sortie> Just saying that if they do want it to be worthwhile, it has to solve a problem an order of magnitude better to compete
<zid> and win32 and .net etc
<sortie> Mostly this thing is just about shutting up the pointless discussions unrelated to the actual topic
<zid> The only gripe I have with posix is sort of just, inertia, that nobody cares enough about getting into a huge war between the drives, the fs layer and posxi to make the filesystem apis more reliable
<MelMalik> even plan 9 has limited posix in the form of ape
<zid> so I end up using sqlite for it instead of native code
<jeaye> "When you are finally done, you are an expert in a custom operating system, and all that knowledge is useless unless you managed to gain market share. " => Do you really think it's useless knowledge, building a custom OS which nobody uses?
<zid> it's useless to build your own house
<zid> all you know is the framing style you used to build it
<jeaye> Seems like it's a huge learning opportunity and a good test of one's design, motivation, and planning.
<Ameisen_> my main gripe with unixy systems is they've already been done to hell and back
<Ameisen_> and I think more work needs to be done in more structured systems
<junon> MelMalik: was a joke ;)
<zid> so have gameboy emulators but I'd still recommend writing one
<Ameisen_> I wrote a MIPS emulator instead
Ameisen_ is now known as Ameisen
<Ameisen> Though my name is finally on an LLVM CL (though not as the author)
<j`ey> Ameisen: gj
<zid> I just moan at people on irc to fix things it's way easier
<MelMalik> zid: but then you didn't do it
<zid> I did a lot of moaning, trust me
Vidius has joined #osdev
<MelMalik> but no fixing
<Ameisen> ;}
<zid> it gets it fixed, through my actions
<zid> ergo I fixed it
<Ameisen> well, there was literally a (popular) blog post about a performance bug
<Ameisen> I actually, you know, wrote test cases and _reported_ it
<zid> see, moaning works
* gog moans at zid
<zid> do I need to call a priest
<gog> probably
wootehfoot has joined #osdev
hzshang has quit [Quit: Client closed]
Vidius has left #osdev [Textual IRC Client: www.textualapp.com]
<Qubasa> So how do I know where grub 2 places the memory map before executing the kernel? Because I discovered that I placed my stack where the grub 2 memory map lies
<geist> that's kinda a toughy. i've generally solved that by putting the initial stack inside the kernel itself
<Qubasa> ahh i see ^^
<geist> ie, in the data or bss segment, then it's part of the kernel's footprint that grub should have taken into account when it loaded it
<Qubasa> Sweet thanks~
<zid> yea I copy mine to 'kernel memory'
<zid> and use a stack in .bss
<Qubasa> Hmm I will do the same then
* kingoffrance blinks "I just moan at people on irc to fix things it's way easier" zid == sky :)
wootehfoot has quit [Read error: Connection reset by peer]
CryptoDavid has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist> huh TIL that SMB supports a file duplicate op
<geist> dunno when that got added but if you copy a file with explorer on a SMB3 samba server w/btrfs it just instantly returns
<geist> and it does a straight up COW copy of the file, verified with filefrag -v
<bslsk05> ​wiki.samba.org: Server-Side Copy - SambaWiki
<Ameisen> ReFS on NT supports copy-on-write, except that _nothing_ exposes it
<geist> been there for a while it looks, i just never had a server backed by a COW filesystem i guess
<MelMalik> oh my
<Ameisen> there's some WinAPIs to handle COW of specific blocks
<Ameisen> it's very frustrating. I'm guessing that they only want it for data deduplication on Windows Server.
<geist> Ameisen: yeah that was my guess why they added the SMB op, they were planning on using refs or whatnot
<Ameisen> but none of the tools at all support COW
<geist> though i guess also having the server do a local copy even without cow is still faster
<Ameisen> What is the fundamental reason that they couldn't add Copy-on-Write support to, say, NTFS?
<Ameisen> Any time I've read on that, people say it's because it's journalled, but I fail to see how that causes an incompatibility.
<geist> well it's just pretty intrinsic to the way extents are recorded and whatnot
<geist> it'd be like adding COW to ext4 or something, would require a fairly fundamental rethinking of how extents and inodes work
<Ameisen> I suppose; my stupid primate brain keeps thinking of a dumb COW implementation as equivalent to just... being a really fancy hard link
<geist> COW fses like WAFL and ZFS and BTRFS are pretty fundamentally designed around it
<junon> Why hasn't BTRFS been more widely adopted?
<Ameisen> I'm not entirely sure why it oculdn't be implemented as a really fancy hard-link, actually
<junon> Or ZFS for that matter
<geist> COW for the whole file yeah, but then the instant you touch it you have to dup it
<Ameisen> because BTRFS somehow manages to have random bouts of instability and data loss
<geist> real COW does it at the extent level
<Ameisen> even whole-file COW would be better than no COW, though
<geist> Ameisen: in the past yes, but i think it's quite stable now
<Ameisen> yeah, but the people who would otherwise be in a position to choose BTRFS have very long memories, to the point that they don't invalidate old/useless data :)
<junon> BTRFS is supposed to be more efficient with write degradation on SSDs right?
<geist> not sure, whole file would be, since you'd now suddenly be signing up for some point in the future suddenly needing to duplicate a shit-ton of data
<Ameisen> Technically, file systems _meant_ for flash memory should be more efficient on SSDs
<junon> Yeah. Imagine an MMAPed file with COW.
<Ameisen> but I've never seen that actually be the case.
<geist> Ameisen: well also people like you just repeat old things like 'its sometimes unstable'
<junon> Any accidental writes to the address space would trigger a full clone, and MMAP is often used to map in gigabytes of data
<Ameisen> I didn't exclude myself from my statement.
<Ameisen> :)
<geist> heh
<Ameisen> though I'm not really in a position to choose BTRFS except on my personal stuff
<Ameisen> I will point out that a big reason it isn't used is that most Linux distro installers don't offer it.
<geist> yah. i use it on personal stuff, and my synology NAS box uses it
<Ameisen> They set up EXT4 (and not really with the ideal flags)
<geist> which is why i suddenly noticed it, like 'wait why did that copy take zero time?'
<Ameisen> I actually was using ReFS on Windows for my development drive
<Ameisen> I switched it back to NTFS, though
<Ameisen> there are just... a lot of issues with using ReFS in such a case
<geist> i wouldn't say most distros dont offer it, they just default to ext4
<geist> and yeha i'm sure most people take the default
<Ameisen> ReFS has issues with hard links, most software that cares about the file system outright does not support ReFS...
<Ameisen> and they made it so you cannot create or repair ReFS partitions unless you have Pro for Workstation or whatever they call it
<geist> yah fundamentally refs is abandoned so that alone kills it
<Ameisen> They are still updating it
<Ameisen> it's just... not used
<geist> same way that reiserfs may still be lovely or whatnot, but it's abandoned AFAICT
<Ameisen> WinBTRFS works, though
<geist> due to prison and whatnot
<Ameisen> though the code is... not great, and it makes me wary of its stability
<Ameisen> it's also slower than NTFS
<Bitweasil> WinBTRFS as a name scares the crap out of me. :p
<Ameisen> hah
<Ameisen> it does work.
<Bitweasil> I don't even want to see the code.
<Bitweasil> I'm sure it does.
<Ameisen> it's... umm...
<Bitweasil> So do many things that ought not work.
<Ameisen> very C-like C++
<Ameisen> but bad C and bad C++
<geist> what are we talking about? nftfs, refs?
<Ameisen> I've also found odd things in it like, in order to zero an extent, they do a bunch of WriteFile ops instead of mapping the extent and memseting it, which is faster.
<klange> gods damned orange site
<geist> welll.. not sure about that (mapping)
GeDaMo has quit [Remote host closed the connection]
<geist> mappig/unmapping may have substantial cost
<Ameisen> in my tests it was
<Ameisen> the kernel is already going to map/unmap for the WriteFile
<geist> sure, but kernel can optimize the wazoo out of that
<Ameisen> it can optimize the wazoo out of a write-only sequential memory map as well
<Ameisen> one less layer
<Ameisen> since you can specify usage parameters for memory maps in WinAPI
* geist shrugs
<geist> alright, you da boss
Oli has quit [Ping timeout: 264 seconds]
<Ameisen> it does depend on what you're doing though
<Ameisen> I've never found plain ol' ReadFile/WriteFile to be faster, though, than the alternatives
<Ameisen> _overlapped_ ReadFile/WriteFile is competitive with memory mapping, though
<Ameisen> but in different ways
<Ameisen> NT just... sort of doesn't do well with normal file ops.
Oli has joined #osdev
<geist> yah possibly true. depends on exactly how it shuffles data from user space to the backing pages
<Ameisen> overlapped ones it does - it knows it can reorder/optimize/merge ops. The non-concurrent ones it cannot.
<geist> also some of that 'needs to map/unmap in kernel' stuff may be obsolete for x86-64?
<geist> perhaps they have much more address space such that defacto it ends up mapped always?
<Ameisen> Might be. They don't really go into detail about the underlying implementation in NT.
<Ameisen> And it might differ betwee XP-64, Vista, 7, 8, 10, and 11
<geist> since lots of systems one way or another have basically all physical ram mapped in the kernel you can fairly easily indirect to the backing page and directly copy
<Ameisen> My knowledge is mostly from my own testing in various environments
<Ameisen> but it might not apply to the usage patterns in a file system
<Ameisen> I do know that I loved using memory mapping on the XB1.
<geist> my usual experience is that mmap/unmap on pretty much all oses has substantial cost so there's a crossover point where it becomes more efficient
<Ameisen> I basically had infinite address space, so it made little sense to not just map every file (in archives)
<geist> like, if you're accessing things many times or the size of the copy is substantial
<geist> we're dealing with this in fuchsia/zircon a lot, since the VM gives user space substantial control over what it does with its memory
<geist> so educating folks on the right way to do things (or finding them in the first place) is fun
<Ameisen> WinAPI memory mapping is a bit different in function than POSIX mmap
<Ameisen> they accomplish the same goals, but WinAPI's is a bit more... 'structured'
<Ameisen> It's a two step process - you create a file mapping object, and then you create file views into it.
<Ameisen> the file view is what gives you a pointer.
<Ameisen> after creating the mapping object, creating file views (should) be relatively cheap
<Ameisen> But, as always, WinAPI stuff is effectively a black box performance-wise
<klange> wheee
<Ameisen> I'd actually have to profile that exact case. I don't normally, in my own stuff, memory map stuff on the fly for temporary ops
<Ameisen> I do recall a somewhat interesting test I did, but it's an odd one.
<Ameisen> I was comparing reading a file, block-decompressing it, and sending it to the GPU, vs mapping the file, passing it through my VEX/page fault-based decompressor, and giving the pointer to D3D11.
<Ameisen> The latter was faster despite the sheer number of page faults
<Ameisen> I write a lot after taking stuff for migraines
<Ameisen> I blame the caffeine
<geist> yah we have some fairly exotic stuff like taht in fuchsia due to EXTREME SANDBOXING
<Ameisen> The bigger issue with WinBTRFS, though, was that it used C-style object cleanup for the various handles/objects, but it did so inconsistently.
<geist> like decompressor processes that are standalone from regular FS server, etc
<Ameisen> I actually gave an example PR that used C++-style RAII to do cleanup, but they didn't want such a significant change... even though I was able to show several memory leaks.
<geist> all moving data through this complex scheme of shared mappings
<Ameisen> I actually still cannot account for -why- it was faster to do it using the fault-based decompressor.
<Ameisen> everything in my head tells me that it should have been slower.
Emil has joined #osdev
m3a has left #osdev [#osdev]
Maka_Albarn has joined #osdev
<Maka_Albarn> I've been digging through the GCC manual, can anyone tell me what section GCC puts the debugging info from -g into? And is it possible to define it in the linker script?
<Maka_Albarn> ...
<Maka_Albarn> scratch the second question.
<zid> .debug_*
<Maka_Albarn> final question: what format would the debugging info be in for i686-elf-gcc?
* Maka_Albarn rubs head sheepishly
mctpyt has quit [Ping timeout: 260 seconds]
<j`ey> DWARF?
<zid> dwarf
* Maka_Albarn beams
<Maka_Albarn> thank you
m3a has joined #osdev
ahlk has quit [Read error: Connection reset by peer]
ahlk has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
Sos has quit [Quit: Leaving]
tacco has quit [Remote host closed the connection]
elderK has joined #osdev
hbag has joined #osdev
<klange> Well, the orange site brought me over 4k stars, so that's nice I guess.
<junon> Holy shit
<klange> not 4k new, just made the total go over 4k
<junon> OH
<junon> Gotcha, what was it before?
<klange> Last month it was ~3690. This morning it was 3960. Currently at 4003.
<junon> Incredible
tacco has joined #osdev
<junon> Alright just finished the first version of the C compiler configurator for the build system I wrote
<junon> That was actually a lot of fun. Good mix of C and Lua.
CryptoDavid has quit [Quit: Connection closed for inactivity]
<junon> Now I have to configure the link rules and I'll be ready to add it to the kernel repository and replace CMake, thankfully.
X-Scale` has joined #osdev
<gog> i remember trying cmake and running as fast as i could back to my little makefile setup lol
X-Scale has quit [Ping timeout: 260 seconds]
<gog> it works for my purposes. certainly not anything larger tho
<MelMalik> merp
<junon> This build system is more like Make than it is CMake, and it's super modular which I like.
<gog> nice
<gog> so is it like the build script is a lua module?
X-Scale` is now known as X-Scale
<junon> I might rip it out of the commons submodule that it currently lives in and release it as its own thing since it's getting quite large now.
<MelMalik> meow
<junon> Yeah, you configure with Lua but using a shebang script basically. The shebang starts the actual build system, which bootstraps itself (looks for a C compiler and compiles the Lua runtime along with some extra C functions), sets up all the paths and everything, then runs the main configuration script.
<gog> oh wow
<gog> MelMalik: mew
<MelMalik> sup gag
<MelMalik> gog*
<junon> The C runtime exposes a number of extra functions, such as running programs during configure-time (to e.g. detect compiler versions and stuff). There's also a standard/internal Lua runtime that bootstraps itself too, which implements all of the path construction and the ultimate Ninja build file generation.