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
<Izem> Who is supposed to be responsible for designing the boot process? Is it the chip/architecture designer? I want to get a bigger picture behind this process.
<heat> what's the boot process?
isaacwoods has quit [Quit: WeeChat 3.2]
<heat> generally the "boot process" is a sequence of smaller processes that are designed independently
<Izem> not boot process but boot loader?
<Izem> Not sure of the terminology
<Izem> but whatever happens before the os takes over
<clever> Izem: uefi, gpt, or one of the many custom arm things?
<clever> s/gpt/legacy/
<Izem> yeah
<clever> for legacy, the only thing really defined, is that the 512 byte MBR is loaded to a certain addr, and executed
<clever> and the bios provides certain utils via soft irq's
<heat> well the firmware's part is "designed" by the board manufacturer (although it's generally a part of a standard in x86 PC)
<clever> everything else is up to the bootloader author
<Izem> yes, that sounds like bios which came in the micro computer days right?
<heat> then you have the bootloader, which is not standardised at all(and part of a larger project, like GRUB and syslinux and microsoft's bootloader)
<clever> heat: thats kinda half just copying the firmware behaviour, so your board is compatible with existing software
<Izem> interesting
<heat> clever: except in UEFI lots of things are shared, no copying, just reuse
<clever> heat: yeah, that was designed in a time of more open things
<heat> I'd totally agree with the statement in the BIOS' case, of course
<clever> there was a whole legal puzzle of doing a clean-room copy of the original IBM bios
<Izem> that kinds indicates why arm has so many things? if the folk that make the boards are making the firmware
<clever> Izem: yeah, on arm, there wasnt really a standard bios (but uefi is trying to take over), so every developer did it differently
<clever> nobody to copy, so they all ran off in different directions
<Izem> clever: is this what uefi had to do to avoid legal trouble, or earlier bios authors? sorry I did not get that bit
<Izem> ah I see
<heat> ealier bios authors
<Izem> ok, that makes sense
<clever> for early bios, they wanted to copy the functionality, so existing os/software could be installed
<Izem> that reminds me, I did see something about uefi and rpi, so it seems uefi is crossing over from the desktop realm
<clever> but with arm, the developer controlled the entire stack, and the end-user isnt going to pick another os
<Izem> yeah
<clever> so they didnt need to be compatible with eachother
<heat> EFI was developed by intel and then they open sourced a bunch of code (called TianoCore), which is mostly shared between vendors AFAIK
<heat> it's designed in a way that allows you to develop each part of the firmware independently
<clever> so now there is a legally valid route to copy it, and have everybody work the same way
<Izem> cool
<clever> uefi also works on arm, as Izem mentioned
<clever> but the rpi uefi is a bit of an ugly hack, given how rpi boots
<Izem> iirc you can boot from address 0 on arm, but anyways what's the hack?
<clever> on most arm boards, the boot rom is mapped to the reset address
<clever> the rom loads an SPL from some fixed offset on flash media
<clever> the SPL brings ram online, and loads the secondary program (hence, SPL == secondary program loader)
<clever> uboot can be built as a combined SPL+uboot blob, filling both roles at once
<clever> and then uboot loads linux
<clever> Izem: all make sense?
<heat> does ARM also have CAR?
<Izem> yeah, it also seems like uboot was for arm stuff from the start? I've always heard of it but I did not look into it
<clever> heat: some chips probably have that
<clever> Izem: for x86, the reset vector points to some flash memory, so it can skip the rom and loading SPL, but that flash memory is slower to access, so the bios will copy itself to ram (after ram init), which is often refered to as the shadow something something...
<clever> (older x86)
<clever> but then on the rpi, its completely different, and yet the same!
<heat> shadow BIOS mapping?
<clever> heat: probably
<clever> on bootup, the VPU (not the ARM) runs a rom at the reset vector
<clever> that rom loads+executes bootcode.bin via cache-as-ram
<clever> bootcode.bin brings ram online, and loads+executes start.elf
<clever> start.elf then puts an "arm stub" at arm physical 0 (the reset vector), followed by a copy of linux, and then enables the arm core(s)
<clever> you can optionally replace the armstub+linux, with uboot, or uefi
<clever> but the whole VPU chain still has to happen first
<Izem> ah cool
<Izem> why did rpi use efi instead of armstub+linux?
<clever> didnt?
<bslsk05> ​github.com: edk2-platforms/Platform/RaspberryPi/RPi4 at master · tianocore/edk2-platforms · GitHub
<Izem> well doesn't rpi have uefi? not the armstub stuff
<clever> efi wasnt as well established back then, and the original rpi boot process was a lot more hacky
<clever> Izem: the rpi uefi stuff, is non-official
<Izem> oh ok
<clever> the original pi1 firmware, was a lot more messy (3-4 stages on the VPU), and looked like it belonged in a cable tv box
<clever> the armstub was also not properly in the firmware
<clever> you had to prepend it to your linux image file, manually!
<clever> they have streamlined it over time, but the rpi devs consider uefi to be pointless
<Izem> wow, not even sure how you would do that, dd maybe
<Izem> yeah, that makes sense
<clever> uefi is all about booting any kernel file on any compatible board
<clever> but the rpi engineers are only focusing on supporting their own os images mainly
<Izem> which makes it easy to multiboot right?
<clever> that too, uefi adds a multi-boot ui to the firmware
<heat> that's all optional though
<clever> heat: i have heard of uefi implementations that can only boot windows, and entirely ignore whatever you write to the efi variables
<heat> the shell and the boot menus are all UEFI applications, just like bootloaders
<clever> "it boots windows, ship it"
<Izem> ok so, do hardware venders for motherboards all make firmware (bios?)
<Izem> haha
<clever> Izem: yeah, the motherboard vendor will create the firmware for it, and include modules they deem useful
<clever> nvme booting, relies on the firmware having nvme drivers
<Izem> interesting
<clever> if you dont put an nvme socket on the motherboard, you may omit nvme drivers
<clever> and then nvme boot doesnt work, even with a pci-e slot adapter
<heat> clever, in theory you can even load your own UEFI DXE drivers using efi vars
<clever> heat: can you put a whole binary in there??
<heat> no.
<Izem> thanks :)
<clever> then you need a sata drive to hold the binary
<heat> I mean, probably, linux dumps to efi vars
<Izem> so bios will probably be around for a while
<clever> at which point, i would just put grub and /boot on sata
<heat> Izem, nope, the BIOS is dead, intel killed it
ElectronApps has joined #osdev
<clever> but there is still bios compatability code in uefi
<Izem> :O
<clever> you can just flip it on, and boot legacy MBR's under uefi
<heat> clever: there are efi vars that let you specify a path inside the system partition; those drivers are then loaded
<heat> they're not a part of the firmware volume but they're still loadable as drivers
<heat> so you can add your own drivers if you want
<clever> i did see a project about building every grub driver into uefi binaries
<heat> the only restriction is that, well, you need to be able to read the/a efi system partition
<clever> so any FS grub supports could be loaded into uefi
<Izem> ok, so say you make an os for the rpi, you consult the rpi devs to see how you will load your os right?
<clever> Izem: apple for example uses uefi, but they added HFS+ drivers to their firmware, so /boot can live on HFS+
<Izem> otherwise you will have to duplicate firmware work
<heat> yeah
<Izem> is that recent?
<clever> Izem: the official start.elf firmware, will just load kernel.img from /boot, and execute it on the arm core
<Izem> I'd always heard efi was to be a fat system
<heat> I'm working on ext4 support for tianocore for example
<clever> Izem: so as long as you have a linux kernel, you can boot like that
<heat> with my patches you can have your efi partition be ext4
<Izem> woah
<Izem> nice!
<heat> yeah
<heat> the issue is that FAT32 is the only file system required by the spec
<heat> you can have support for others but FAT is always required
<Izem> yeah, so for others why bother support more stuff
<Izem> it's not a big deal since the kernel image is never gonna be that big?
<clever> Izem: lack of a journaled FS
<clever> one improper shutdown at the right time, and your /boot is corrupted
<Izem> right, that sucks
<heat> ext4 has extents, lots of checksums, journaling, better posix integration
<heat> if you try a bit harder you can even have an ext4 driver that supports 2 and 3
<clever> with fat32, you could kinda do atomic rename() if you just change the starting cluster for a given file
<clever> but if that sector is partially written, the directory table is now corrupt
<clever> oh right, and the root directory, has a max file count
<Izem> side question, how come fat seems to be the system everyone supports? doesn't seem to be much others
<clever> i ran into that on an old mp3 player
<Izem> I guess fat is supposed to be simple right?
<heat> Izem: UEFI was heavily influenced by intel and microsoft
<clever> the mp3 player didnt support directories (lol), and when the root folder is full, you cant fit any more music on it
<Izem> good point :P
<clever> it only had 128mb of internal flash, but supported 2gig sd cards
<heat> there used to be a special EFI file system (from what I gathered while talking to more experienced folks) but they ditched it for FAT
<clever> Izem: oh, and dont even ask about long filenames on fat.....
<Izem> haha
<clever> implementing that is a legal grey zone
<Izem> at least names are not required to be in caps
<heat> they are
<heat> EFI file systems are required to be case insensitive
<Izem> oh
* Izem checks
<heat> \BoOt\EfI\VmLINux -> \BOOT\EFI\VMLINUX
<Izem> I see
<heat> you have to do case-insensitive string compares
<clever> [root@system76:~]# efibootmgr -v
<clever> BootCurrent: 0004
<clever> BootOrder: 0004,0000,0001,0002,0003
<clever> Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<heat> and those require really complicated unicode collation support
<clever> BootCurrent says what os is currently running (how it got to whatever its running now), BootOrder is what order it tries things in
<clever> /dev/nvme0n1p1: UUID="7DBC-2698" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8"
<clever> Boot0004 says to find a GPT partition with PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8", mount that, and then execute \EFI\BOOT\BOOTX64.EFI
<Izem> "Boot0004* FedoraHD(1,GPT,36541d07-6a04-4fcb-990e-6a542dd30159,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)"
<Izem> guess that is a symlink or something?
<heat> no
<clever> -rwxr-xr-x 1 root root 139264 Jun 21 22:30 /boot/EFI/BOOT/BOOTX64.EFI
<heat> fedora has a shim for secure boot purposes
<Izem> oh
<clever> if i run strings on my .efi, i can see its just grub
<heat> shim is signed, the kernel isn't required to be
<Izem> nice
<clever> heat: but i can just backdoor your kernel, and your shim will happily run it
<clever> then when you enter your luks pw, your screwed
<heat> not quite iirc
<clever> depends on how things are configured i think
<clever> does the shim require signatures?
<heat> they do some key signedness checking
<clever> there is also measured boot, where each stage will hash the next stage, and report it to the TPM, before passing control on
<clever> and if you play back the same sequence of hashes, the TPM will unlock some keys
<heat> the important part is that the shimx64 is microsoft signed, the kernel doesn't need to be(just needs to have a valid signature)
<clever> if any stage in the chain is modified, it wont unlock itself
<Izem> who benefits from this design?
<clever> Izem: secureboot, when done properly, protects you from evil maid attacks
<bslsk05> ​wiki.archlinux.org: Unified Extensible Firmware Interface/Secure Boot - ArchWiki
<clever> as does measured boot
<Izem> sounds hardcore
<clever> basically, secureboot means the system will just not boot, if the evil-maid modifies anything in the boot process
<clever> and measured boot, encrypts the hdd
<clever> so any attempt to hack the system, will instead just brick it
<clever> and only somebody with the bios pw, can recover things
<heat> note that a UEFI application that just mindlessly loads anything would never be signed by microsoft
<Izem> yeah, what if that's the goal? like some sort of dos attack
<Izem> ah good point
<clever> Izem: what if i break into your hotel room, and modify your laptop to install some malware?
<Izem> ah I see lol
<heat> that's why the shim checks for keys, that's why your linux kernel checks for signed modules, etc
<clever> an encrypted hdd stops me from just changing the os directly
<clever> measured boot provides auto-decryption, so you dont have to enter a pw on startup
<clever> secure boot stops me from editing the non-encrypted kernel files
<clever> my only option left now, is to replace the motherboard :P
<Izem> I was thinking more of data centers not hotel rooms, but I think I get your point
<clever> the secondary problem, and why that shim is signed by microsoft
<heat> way more dangerous to have a compromised computer than a "oh no borken computer what do now!"
<clever> microsoft is making deals with OEM's, to have the uefi only boot things signed by MS, and nothing else
<clever> so the firmware will only run an os that microsoft approves of
<Izem> sounds kinda weird but it makes sense
<clever> in the case of my main desktop, i believe i can load my own custom certs into the firmware
<clever> and then it will only execute things i signed
<clever> but ive not played with it
<heat> someone has to sign stuff and people would without a doubt complain about anyone
<clever> partially, because my distro doesnt support it
<Izem> true
<heat> Intel does it? oh no intel bad. Red hat? same thing
<clever> also, you need to heavily lock down the os, to make it worth anything
<clever> lets say secureboot was done properly, and only an authorized linux kernel can execute
<clever> but the kernel modules arent checked
<clever> 5 seconds with insmod, and i have ring0, and can then run any un-authorized kernel
<Izem> then they could load some bad stuff
<Izem> yeah
<clever> so i could modify your bootloader to run the signed linux, load a module, then kexec to an unsigned linux
<clever> the unsigned linux will record your passwords, and report home when you get online
<clever> then i just put it back in your hotel room, and wait
<Izem> D:
<clever> and an evil maid doesnt even have to break in
<clever> she has the master key to every room in the building!
<Izem> you sure I can't just put blockchain in the bootloader? :P
<clever> but i'm sure police and other govt agencies could convince the hotel staff to open the doors
<clever> oh, and this is also why VM acceleration is often disabled in the bios
<clever> what if i replace your bootloader with a virtual machine, that then runs your original so as a guest
<Izem> to make this type of attack harder?
<Izem> yikes
<clever> then your os cant detect anything
<clever> because the VM hw lies to it
<heat> you can always detect a hypervisor
<clever> you wont even notice a performance difference, because of the VM acceleration
<Izem> can't you still run a VM but it will be slow? that's what I thought it was for
<Izem> yeah
<clever> heat: how?
<heat> clever: lots of anti-cheats do it
<heat> how? I don't know. but they do it
<Izem> be cool to meet some of the folks making these things lol
<clever> that sounds like detecting legit VM's
<clever> hacking VM's wont advertise themselves
<Izem> yeah :/
<clever> and can just trap detection stuff, and emulate what hw would have done
<clever> a normal vm wont give you access to the real hw, because its a security problem
<bslsk05> ​www.reddit.com: Warning to all Faceit (and possibly ESEA) players! Playing in KVM VM with GPU passthrough might get you banned! : linux_gaming
<clever> but a hacking VM could expose the real hw, and use an IOMMU to partition off a tiny bit of its own ram
<heat> ^^two popular csgo anticheats
<clever> that sounds like qemu with gpu passthru, which will advertise itself all over the place
<clever> there will be qemu devices all over the lspci tree
<heat> they used tweaks to hide KVM and it worked until it didn't
<clever> you dont even have to try, to detect it
<clever> yeah, at that point, it just turns into an endless game of cat&mouse
<clever> each side finding new detection strats, and then patching them out
<heat> the only qemu device in a default qemu-system-x86_64 is the VGA controller
<clever> it should also advertise itself in the acpi
<clever> and maybe cpuid?
<clever> and the whole bios build
<clever> also, would qemu even show a northbridge + southbridge in pci?
<clever> a pc without a northbridge is a giant red flag
<clever> a malware type VM, would just expose all of the pci devices directly, so such hints would just vanish
<heat> clever, vm exits can leak
<heat> that's a *huge* issue
<clever> maybe people (like me) over-estimating the power of the vm hw, is what led to such fears, and off buttons
tacco has quit []
iorem has joined #osdev
Izem has quit [Quit: rcirc on GNU Emacs 27.2]
CryptoDavid has quit [Quit: Connection closed for inactivity]
zoey has quit [Ping timeout: 240 seconds]
sts-q has quit [Ping timeout: 268 seconds]
srjek has quit [Ping timeout: 256 seconds]
zaquest has quit [Quit: Leaving]
zaquest has joined #osdev
Matt|home has quit [Ping timeout: 255 seconds]
Matt|home has joined #osdev
dude12312414 has joined #osdev
nyah has quit [Ping timeout: 255 seconds]
dude12312414 has quit [Ping timeout: 244 seconds]
thinkpol has quit [Remote host closed the connection]
wille has quit [Quit: The Lounge - https://thelounge.chat]
thinkpol has joined #osdev
heat has quit [Ping timeout: 265 seconds]
dude12312414 has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
andydude has joined #osdev
catern has quit [Ping timeout: 240 seconds]
andydude has quit [Quit: andydude]
Mikaku has joined #osdev
Izem has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Izem has left #osdev [rcirc on GNU Emacs 27.2]
MarchHare has quit [Quit: Leaving]
<moon-child> I added syntax highlighting to my text editor, and now it's dog slow
<moon-child> there's no caching, so it re-highlights everything on every keypress, but vim can still re-highlight a page of text an order of magnitude faster
<mjg> and vim is already slow
elastic_dog has quit [Ping timeout: 255 seconds]
<moon-child> I find vim is pretty snappy for everything except raku
<moon-child> (and very long lines, though that's unrelated to syntax highlighting)
elastic_dog has joined #osdev
<kingoffrance> speak of the devil "and now it's dog slow"
<dzwdz> do syscalls usually use the same paging directory as the calling process?
<klange> That... is a more complicated question than you may realize.
<klange> So traditionally, yes, for a long time that was common - why pay the penalty of having to switch directories on entry into the kernel? After all, that's what all those virtual memory permission bit things are for, right, keeping the kernel separated from userspace?
<klange> But then some stuff happened now the norm in 'real' OSes is to only keep the bare minimum of kernel mappings in place - a 'trampoline' of pages necessary to respond to various entry points (interrupts or whatever) and then switch to the real directory when you get to the kernel.
<dzwdz> that's due to spectre, right?
<klange> one of those things, yeah
<dzwdz> and what happens when the kernel wants to read user memory? does it parse the page dirs on its own?
<klange> For a long while even before the great switching, most kernels had APIs for "copy from user" / "copy to user" which may have been doing bounds checks or whatever, and then now they can map things somewhere to perform the copies in and out.
<dzwdz> where do they map them? in their own page directory?
<j`ey> yes
<dzwdz> is it even worth it performance-wise? if i'm iterating over the page tables anyways, i could just copy a page at a time
<klange> You still need to map _that_ page somewhere.
<dzwdz> what if the kernel uses an identity mapping spanning the whole physical address space?
<klange> that's somewhere
ElectronApps has quit [Remote host closed the connection]
dennis95 has joined #osdev
ElectronApps has joined #osdev
transistor has quit [Ping timeout: 252 seconds]
transistor has joined #osdev
zoey has joined #osdev
pony has quit [Quit: WeeChat 2.8]
pony has joined #osdev
mcfrdy has joined #osdev
GeDaMo has joined #osdev
Belxjander has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
<klange> moon-child: my editor's older C highlighter was really fast and could effectively highlight its own 10k line source every keystroke if it really wanted to ;)
<klange> And then I embedded my Python knock-off and ported all the syntax highlighting to that, and now it takes a second or two to do that much, so having a smarter highlighter is important.
<moon-child> yea, this is highlighter in scheme, and it has to restart for every token
<moon-child> if i did it in c and oneshot probably it would be that fast
<moon-child> but that it's _this_ slow indicates something else somewhere is fundamentally wrong
<klange> Even after the language port, I've got the same general system going, and I've got all sorts of little tricks to reduce rehighlighting... and then I threw in even more tricks with highlighting 'in the background' with some dirty fake coroutine things.
englishm has quit [Ping timeout: 252 seconds]
<moon-child> oooh, actually that gives me an idea
<moon-child> can use call/cc to handle ambiguous parses
<moon-child> restart the continuation until it gives a valid parse
<moon-child> I'm sure this is a horrible idea in practice, _but_
<klange> If you peel back the covers, all editors are little more than a bunch of horrible ideas.
<moon-child> lol
pony has quit [Quit: WeeChat 2.8]
pony has joined #osdev
dormito has joined #osdev
CryptoDavid has joined #osdev
nyah has joined #osdev
kwilczynski has quit [Quit: Connection closed for inactivity]
wille has joined #osdev
<sortie> Today in me going mad in osdev: I have one perl source directory that builds correctly and another one that doesn't.
<sortie> (Natively on my OS, well it builds, but the installed perl is defective)
<sortie> The difference is partly my own patches being slightly updated, and also that the old dir isn't distclean. (Oh god perl is terrible at cleaning its source directory)
pony has left #osdev [#osdev]
ElectronApps has quit [Read error: Connection reset by peer]
<sortie> Been going mad trying to bisect this difference, turns out it's also due to the installed stuff in /lib/perl5, so one test could taint the next
ElectronApps has joined #osdev
<sortie> The new source dir has all the files in the upstream perl and perl-cross releases, so it's not that anything is missing
<sortie> My best bet is that when I cross-compiled perl on Linux and made that old directory, it populated it with some files that got picked up when I used the source directory on my OS, and when I built a proper distclean, it deleted those files. But due to some bug in my OS, they don't get properly recreated when doing a native build, and the perl isn't fully featured
pony has joined #osdev
<sortie> Hmm also happens when I cross-compile
isaacwoods has joined #osdev
ahalaney has joined #osdev
Ameisen_ has quit [Quit: Quitting]
Ameisen has joined #osdev
klysm has quit [Ping timeout: 265 seconds]
clever has quit [Ping timeout: 265 seconds]
klysm has joined #osdev
wille3 has joined #osdev
dennisschagt_ has joined #osdev
wolfshappen_ has joined #osdev
NieDzejkob_ has joined #osdev
Terlisimo1 has joined #osdev
Terlisimo has quit [Ping timeout: 255 seconds]
froggey has quit [Ping timeout: 255 seconds]
koolazer has quit [Ping timeout: 255 seconds]
kanzure has quit [Ping timeout: 255 seconds]
wille has quit [Ping timeout: 255 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
thinkpol has quit [Ping timeout: 255 seconds]
Mikaku has quit [Ping timeout: 255 seconds]
NieDzejkob has quit [Ping timeout: 255 seconds]
dennisschagt has quit [Ping timeout: 255 seconds]
wolfshappen has quit [Ping timeout: 255 seconds]
kingoffrance has quit [Ping timeout: 255 seconds]
nur has quit [Ping timeout: 255 seconds]
wille3 is now known as wille
koolazer has joined #osdev
Bonstra has quit [Quit: Pouf c'est tout !]
kanzure has joined #osdev
froggey has joined #osdev
elastic_dog has joined #osdev
Mikaku has joined #osdev
Bonstra has joined #osdev
kingoffrance has joined #osdev
clever has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
heat has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 272 seconds]
heat_ is now known as heat
nur has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
z_is_stimky_ has quit [Read error: Connection reset by peer]
z_is_stimky has joined #osdev
gog has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<gog> mew
<dzwdz> mewtwo
<heat> mewthree
SGautam has joined #osdev
terrorjack has quit [Remote host closed the connection]
terrorjack has joined #osdev
gareppa has joined #osdev
Izem has joined #osdev
Izem has quit [Remote host closed the connection]
vai has quit [Ping timeout: 258 seconds]
* Bitweasil makes... whatever sound a mustalid trying to mew is.
<bslsk05> ​'Baby Ferret Noises' by Earthling1984 (00:00:25)
<Bitweasil> Fair. :D
<Bitweasil> I've never had baby ferrets, all mine are older rescues, usually 8+ months old.
<dzwdz> are baby ferrets supposed to act like this? it kinda looks scared
<Bitweasil> Oh, that's not a baby, that's just a young ferret. And that's perfectly normal.
<Bitweasil> They're... very bouncy. Lots of Tigger in them.
<gog> yeah mustelids do this "dance" when they're hunting
mctpyt has quit [Ping timeout: 258 seconds]
<gog> this one is playing :p
<Bitweasil> They hold that energy to about 2-3 years old, then start gradually slowing down.
<Bitweasil> Indeed. That's just a ferret having fun.
<dzwdz> also, how many ferrets do you have?
<dzwdz> that sounds pretty fun
<Bitweasil> ... probably one that was in a cage, if they've got more space to run around endlessly, they're a bit calmer when they come out.
<Bitweasil> The hyper "spring uncoiling" behavior is usually if they've been left in a cage for a while (even a larger cage). They need a bit more space.
<Bitweasil> Currently, 3, generally between 2 and 5.
<Bitweasil> They've got... oh, 50+ sq ft of walled in area in a room they can play in, with a ton of tubes, couple cages to sleep in if they want, etc.
<Bitweasil> And we let them run around the house as well at times.
<dzwdz> > between 2 and 5
<dzwdz> do you run a rescue or something?
<Bitweasil> It's not popular right now in the heat, but I've got a little travel cage that has a 10' tube feeding into it, so there's a nice run into it, and they really like it in the winter - I cover it with blankets and they just fur pile in there.
<Bitweasil> ... no?
<Bitweasil> That's a sane personal ferret count.
<Bitweasil> I mean, all mine are rescues, but I don't run a rescue, nor do I try to rehome them. They come here and stay. :)
mctpyt has joined #osdev
<Bitweasil> 3-4 is ideal.
<heat> my weakness is people talking about summer and thermal issues :(
<dzwdz> they come to you on their own? wow
<Bitweasil> ...
<Bitweasil> Are you being deliberately obtuse?
<dzwdz> no
<dzwdz> i just didn't know that ferrets do that
<Bitweasil> We go out and find ferrets that people are looking to rehome when we're low.
<Bitweasil> They're... about like a cat, socially.
<dzwdz> ah ok
gareppa has quit [Quit: Leaving]
<kingoffrance> so, 4 against elastic_dog
<GeDaMo> The Internet is run by ferrets, they carry the packets down the tubes :|
<gog> ferrets, hamsters, rabbits, and moles
<heat> fiber optic is a lie
gog has quit [Quit: bye]
gog has joined #osdev
<Bitweasil> Sounds about right.
tacco has joined #osdev
freakazoid333 has joined #osdev
aleamb has joined #osdev
<Bitweasil> ARM timers support "event streams" - that sends events that trip the WFE (Wait For Event) instruction and such.
<Bitweasil> What *are* "events" in ARM? :/
<clever> Bitweasil: wfe (wait for event) and sev (send event)
<clever> my understanding, is that events are just a global broadcast, to wake up every core in wfe
<clever> so you can skip having to deal with the external interrupt controller?
<Bitweasil> *nods* I'm unclear as to if they're delivered as exceptions, or what, exactly.
<Bitweasil> No, I get to deal with that too. :p
<Bitweasil> Or if I need new "event" plumbing.
<clever> i think they ONLY un-pause wfe, and nothing else
<Bitweasil> But timers can send them too.
<clever> also, its semi sticky, if you receive an event, then wfe, the wfe will clear the flag, and continue
<Bitweasil> The generic timer can send event streams that unblock WFE.
<clever> so you could wfe for a timer to tick over, and then not deal with exceptions
freakazoid333 has quit [Read error: Connection reset by peer]
<Bitweasil> Yeah, I think timer events are "a different thing."
<Bitweasil> "The following events are WFE wake-up events: ... an event sent by the timer event stream."
<clever> i think its for lower latency gpio things?
<clever> set a timer, wfe, then poke a gpio, for example
<clever> rather then enabling interrupts, waiting for the exception, confirming what irq it was, then poking gpio
<Bitweasil> Right, I don't care what it's used for, I care how it's implemented. :)
dennis95 has quit [Quit: Leaving]
iorem has quit [Quit: Connection closed]
terrorjack has quit [Read error: Connection reset by peer]
immibis has joined #osdev
terrorjack has joined #osdev
nvmd has quit [Quit: Later, nerds.]
johnjay has quit [Ping timeout: 268 seconds]
freakazoid333 has joined #osdev
GeDaMo has quit [Quit: Leaving.]
freakazoid333 has quit [Read error: Connection reset by peer]
mhall has quit [Quit: Connection closed for inactivity]
<sortie> https://xkcd.com/349/ ← Me, fixing my perl port, deep in the rabbit hole, and now make(1) itself is stuck using 100% time solving the halting problem
<bslsk05> ​xkcd - Success
<bslsk05> ​'Hal fixing a light bulb' by Gordon Myers (00:00:42)
<sortie> sortie and mjg at at Tanagra
dormito has quit [Ping timeout: 240 seconds]
terrorjack has quit [Read error: Connection reset by peer]
CryptoDavid has quit [Quit: Connection closed for inactivity]
terrorjack has joined #osdev
<immibis> I found out the other day that all you have to do to solve the halting problem is to define H(paradoxical program)=false and spend 2 years writing an academic paper to convince yourself this is correct
<moon-child> what is a paradoxical program?
dormito has joined #osdev
<clever> moon-child: this statement is a lie
<moon-child> that is not a program
<sortie> Well.. make only locks up when building -jN
<immibis> void f(x) {if(program_halts_with_argument(x, x)) infinite_loop();}
<moon-child> clever: in particular, a sound type system will reject formulations such as that
<immibis> int main() {print(program_halts_with_argument(f, f));}
<immibis> it's the halting problem equivalent of "this sentence is false" and has no correct answer
<moon-child> immibis: that's not a solution to the halting problem, that's a proof by contradiction that the halting problem cannot be solved
<immibis> moon-child: correct. but if you define program_halts_with_argument(f,f)==false and then spend 2 years writing an academic paper to convince yourself that's a solution, it can be a solution too!
<immibis> despite the fact that with this definition, f(f) clearly does halt.
<moon-child> there's a guy on usenet who keeps claiming to have solved the halting problem
<moon-child> I don't think he even had to write an academic paper!
<sortie> Well my problem went away as mysteriously as it appeared
<sortie> Normally that terrifies me but a dirty perl tree seems to have so many fucked up aspects that I'll just say it was in a bad state somehow and pray
<zid> moon-child: I already solved the halting problem, pfft
<zid> The solution is to not give a shit about any classes of problems where it applies
freakazoid333 has joined #osdev
ahalaney has quit [Quit: Leaving]
gog has quit [Ping timeout: 265 seconds]
<bslsk05> ​softwareengineering.stackexchange.com: algorithms - Does H correctly decide that P (source-code provided) never halts? - Software Engineering Stack Exchange
<bslsk05> ​www.researchgate.net: (PDF) Halting problem undecidability and infinitely nested simulation
<moon-child> zid: sounds like dhall
<immibis> basically: H is an x86 simulator, when the simulator encounters a call to H(f,f) it doesn't call H but rather just calls f(f) directly. Therefore f(f) is infinitely recursive in the simulator and never halts.
<immibis> obvious problem: this is not how H(f,f) actually behaves
<immibis> obvious solution: just delude yourself until you don't understand why that's a problem
V has quit [Remote host closed the connection]
V has joined #osdev
<zid> immibis: skyhooks!
dutch has quit [Quit: WeeChat 3.2]
dutch has joined #osdev
heat has quit [Read error: Connection reset by peer]
wgrant has quit [Ping timeout: 268 seconds]
terrorjack has quit [Read error: Connection reset by peer]
terrorjack has joined #osdev
srjek has joined #osdev
johnjay has joined #osdev
sortie has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 258 seconds]