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=18&m=7&d=9

Monday, 9 July 2018

00:00:00 --- log: started osdev/18.07.09
00:00:19 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
00:03:56 --- quit: M1cha (Ping timeout: 255 seconds)
00:14:55 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
00:18:44 --- quit: variable (Ping timeout: 276 seconds)
00:19:18 --- quit: froggey (Ping timeout: 276 seconds)
00:25:24 --- join: sixand (~Thunderbi@222.84.223.232) joined #osdev
00:26:22 <absolute123> i know how it works, in case of pointers, it accesses different pool of stuff with delay and marks the operation as whole array, but the first decision to execute an instruction or not is made based of persistent pool
00:30:51 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
00:33:13 --- quit: spare (Quit: leaving)
00:34:45 <klange> 98 handles with this protocol... that sounds wrong
00:36:02 --- join: Guest4630 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
00:37:32 <Mutabah> klange: can't _handle_ that many?
00:37:34 * Mutabah runs
00:37:39 <klange> I was expecting 1.
00:38:03 <klange> It's a protocol that's supposed to represent an object containing the device path from the file that was launched by EFI... there should only be one of those!
00:38:20 <klange> I'll have to print more info
00:38:25 <absolute123> anyhow, you're sort of asking how it goes back to the handler? when the occupancy per instruction is full occupancy, it will skip with wid conflict every other instruction in the fifo, and hence start from the beginning
00:39:28 --- quit: mra90 (Read error: Connection reset by peer)
00:39:45 --- kick: absolute123 was kicked by Mutabah (Noise reduction)
00:40:12 <Mutabah> klange: Huh... damn, now I want to do EFI stuff again
00:40:18 <Mutabah> but I'm at work
00:40:48 --- join: vodka123 (~vodka@168.126.166.251) joined #osdev
00:41:35 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:42:08 <vodka123> genitals reduction to Mutabah happens also shortly, i end up my work, will gonna visit him
00:42:19 <vodka123> and see what other reductions are possible
00:42:24 <vodka123> nose reduction etc.
00:42:29 --- kick: vodka123 was kicked by Mutabah (vodka123)
00:46:19 --- quit: macdonag2 (Quit: macdonag2)
00:46:33 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:49:50 --- quit: trout (Ping timeout: 276 seconds)
00:51:43 --- quit: AverageJ0e (Ping timeout: 264 seconds)
01:02:27 --- quit: [Alucard] (Quit: There are paranoid crossroads and shipwreck alleys.)
01:03:33 --- join: [WildCard] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
01:05:13 --- quit: Stary[m] (Ping timeout: 245 seconds)
01:05:13 --- quit: kataria[m] (Ping timeout: 245 seconds)
01:05:14 --- quit: caseypme[m] (Ping timeout: 240 seconds)
01:05:43 --- quit: lkurusa (Ping timeout: 240 seconds)
01:05:43 --- quit: dafnamay[m] (Ping timeout: 240 seconds)
01:06:30 <Sjors> we should train a markov chain on whatever this guy comes in to say
01:06:44 --- nick: hussein -> nur
01:06:50 <Sjors> something like this: https://en.wikipedia.org/wiki/MegaHAL
01:07:24 <bslsk05> ​en.wikipedia.org: MegaHAL - Wikipedia
01:07:55 <Sjors> it will surely pass the turing test for being exactly as unfollowable as the original text
01:08:31 <Mutabah> I wonder what happens if you train markov chains recursively
01:08:40 <Mutabah> I guess they'd converge on the same table
01:14:23 --- quit: sixand (Ping timeout: 256 seconds)
01:17:59 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
01:20:19 --- join: sixand (~Thunderbi@222.84.223.232) joined #osdev
01:21:15 --- quit: variable (Ping timeout: 260 seconds)
01:24:04 --- quit: celadon (Quit: ZNC 1.7.0+deb1+b1 - https://znc.in)
01:24:18 --- join: Asu (~sdelang@205.203.136.77.rev.sfr.net) joined #osdev
01:24:23 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
01:24:44 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
01:26:18 --- join: Stary[m] (starymatri@gateway/shell/matrix.org/x-pkrigozbqpmgjmiy) joined #osdev
01:27:34 --- join: kataria[m] (katariamat@gateway/shell/matrix.org/x-oankmkbgbuqsepjk) joined #osdev
01:29:23 --- join: lkurusa (lkurusamat@fedora/Levex) joined #osdev
01:29:31 --- quit: AverageJ0e (Ping timeout: 264 seconds)
01:30:10 --- join: dafnamay[m] (dafnamayma@gateway/shell/matrix.org/x-epkbmlvcqqbhcdgp) joined #osdev
01:31:23 --- join: caseypme[m] (caseypmema@gateway/shell/matrix.org/x-vblpnymhjbntezju) joined #osdev
01:36:09 --- quit: graphene (Remote host closed the connection)
01:37:41 --- join: graphene (~graphene@46.101.134.251) joined #osdev
01:40:20 --- quit: ybyourmom (Quit: Lost terminal)
01:42:25 --- quit: grouse (Read error: Connection reset by peer)
01:43:02 <doug16k> I just got a friend to check his system monitor handle count in windows 10. it's over 90000 :)
01:43:11 <doug16k> what could possibly have that much open D:
01:44:12 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
01:47:09 --- quit: graphene (Remote host closed the connection)
01:48:37 --- join: graphene (~graphene@46.101.134.251) joined #osdev
01:49:48 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
01:51:32 <doug16k> klange, my bootloader supports FAT or ISO9660, if that's what you meant
01:52:11 <doug16k> do you mean directly reading the disk and using your own filesystem? that's what the BLOCK APIs are
01:52:32 <klange> Yeah, but I'm more interested in the moment with actually finding the right device to read from.
01:52:42 --- quit: trout (Ping timeout: 240 seconds)
01:52:50 <doug16k> you query that interface from your executable handle
01:52:57 <Mutabah> I just use the FS APIs and load the kernel from the boot device - but I'm being lazy
01:52:57 <doug16k> I do it but don't use it
01:53:10 <jjuran> WHAT!? 90,000??
01:53:16 <klange> Okay, but how do I get from my executable - which is in an embedded FAT - back to the ISO9660 filesystem on the rest of the CD.
01:54:22 <Mutabah> Why is your bootloader in a FAT image? I thought EFI coudl load from iso9660 when cdbooting?
01:54:42 --- quit: vdamewood (Ping timeout: 240 seconds)
01:54:43 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-dmyxorlxklmeqegk) joined #osdev
01:54:43 <doug16k> ah that might not be so trivial. when you get the block I/O handle I think I remember it being a partition handle
01:55:15 <klange> Mutabah: apparently not - or at least, OVMF does not support it
01:55:40 <Mutabah> aww
01:55:44 <doug16k> this gives you a raw block level API for the device containing the boot program -> https://github.com/doug65536/dgos/blob/master/boot/bootefi.cc#L183
01:55:44 <klange> UEFI itself says nothing about ISO9660 support, only FAT, so also support ISO9660 seems to be an extension implemented by some, but not all, implementations.
01:55:45 <bslsk05> ​github.com: dgos/bootefi.cc at master · doug65536/dgos · GitHub
01:55:53 <doug16k> but I don't remember whether it is the partition or whole drive
01:56:20 <klange> It has a flag, can probably check and work backwards from there to find the actual device if necessary.
01:57:53 <doug16k> I was considering just using my filesystem implementation instead of trusting the EFI one, through block I/O, but I decided to just use theirs out of curiosity
01:58:08 --- quit: graphene (Remote host closed the connection)
01:58:38 <doug16k> it would be a pretty small change to switch it over
01:58:43 --- quit: hmmmm (Remote host closed the connection)
01:59:35 --- join: graphene (~graphene@46.101.134.251) joined #osdev
02:03:02 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
02:03:20 <doug16k> I started on an ext filesystem implementation, but it's hard to stay motivated to work on it because I dislike how it represents the file fragments as a radix tree. it's less ridiculous than a linked list I guess but man, it must cause a lot of seeks
02:05:04 <doug16k> it's also full of special cases
02:05:35 --- join: matryoshka (~matryoshk@unaffiliated/matryoshka) joined #osdev
02:07:46 <klange> Another option, since FAT and ISO are both single-extent, is to hack up the ISO so that both the FAT and ISO have the same files.
02:07:59 <klange> I've done worse things to ISO filesystems.
02:08:18 <doug16k> Mutabah, it doesn't support iso9660. you know the "boot program" that el-torito loads? in efi scenario that file is actually a FAT partition image, it mounts that and continues as if it was FAT
02:08:18 * Mutabah is away (Out)
02:09:02 <klange> One thing I liked to do with my ISOs was to put a file on them that referenced the whole image. SELF.ISO
02:09:59 <doug16k> klange, interesting. I'd imagine that validation tools might see that as an error
02:10:50 <doug16k> though I don't remember sharing blocks being disallowed in the spec
02:12:00 <klange> Even Windows was happy to accept my weird overlapping files, so I think I'd be okay.
02:12:09 <klange> Windows even happily accepted the one that was also a PDF.
02:12:35 <doug16k> ah you put a PDF header in the reserved area? neat. yeah I remember that
02:15:24 <doug16k> ah I see what you mean... build FAT metadata that shares the data blocks with the ISO image, and make the FAT partition overlap the ISO filesystem. clever!
02:19:01 <doug16k> if you wanted to go all out, have a system+hidden file in the FAT metadata that links together all of the ISO blocks, so they won't get moved if they defrag it
02:19:35 <doug16k> IIRC defrag tools typically don't touch system+hidden files. at least that was true at some point
02:20:18 <Brnocrist> https://riscv-basics.com/
02:20:19 <Brnocrist> wtf
02:20:19 <bslsk05> ​riscv-basics.com: RISC Architecture: Understanding the Facts – Arm
02:21:19 <doug16k> Brnocrist, they're afraid :)
02:21:56 <Brnocrist> yeah
02:23:20 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
02:25:11 --- quit: variable (Ping timeout: 245 seconds)
02:25:32 --- join: Kimundi__ (~Kimundi@i577A90CB.versanet.de) joined #osdev
02:25:53 --- join: froggey (~froggey@unaffiliated/froggey) joined #osdev
02:29:07 <klange> So I figure, ISO is capable of appends in the right setup... Just need to start with the FAT, put all the files in it, then append equivalent entries in the ISO based on the blocks FAT gives. Since it's primarily an ISO image, it's expected it'll be on a read-only medium, so tools should try to defrag the embedded fat anyway, even if it were mounted in a read-write manner.
02:29:52 <doug16k> klange, it is possible to coerce mastering tools to put files in a specific order. if you built the fat metadata as a file with all zero-size directory entries, got it to be close enough to the start of the disk, then you could patch the directory entries and FAT to point to the ISO data blocks
02:32:23 <klange> Either way should work. I just figure it's easiest to get xorriso to point to the completed FAT as the first step and work from there.
02:36:12 --- quit: vdamewood (Ping timeout: 240 seconds)
02:36:24 <doug16k> I wonder how feasible it is to patch genisoimage (or xorriso, or whatever) to do it automatically instead of tweaking the output
02:37:00 <doug16k> they'd probably have all the information needed in convenient data structures
02:37:34 <klange> sortie wrote tools to extend ISOs, I might look at those.
02:37:36 <doug16k> or leverage the code it has for multisession - cd fs already has to do that
02:37:52 <doug16k> (sharing the old blocks in the new metadata)
02:37:53 <klange> I think that's how sortie does his ISO extensions.
02:38:04 <klange> Anyway, let me go home and do this...
02:42:20 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
02:52:13 --- quit: xenos1984 (Quit: Leaving.)
02:55:04 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
02:57:12 --- quit: trout (Ping timeout: 240 seconds)
03:04:54 --- quit: w41 (Ping timeout: 244 seconds)
03:06:59 --- quit: NaNkeen (Ping timeout: 276 seconds)
03:16:02 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
03:27:02 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
03:27:25 <FreeFull> klange: I wonder if that's how Haiku anyboot ISOs work
03:27:37 <FreeFull> Or if it's just that writing any ISO to a USB stick works
03:27:47 <FreeFull> For the purposes of booting, I mean
03:28:40 <clever> FreeFull: ive looked at how nixos does it, and the trick is that the cdrom filesystem just ignores the first 32kb of the disk, so you can shove in an MBR or GPT table, that refers to the same offset that the cdrom uses
03:29:21 --- quit: variable (Ping timeout: 245 seconds)
03:32:17 --- quit: sixand (Ping timeout: 244 seconds)
03:35:03 --- join: m_t (~m_t@p5DDA2FB6.dip0.t-ipconnect.de) joined #osdev
03:36:18 <FreeFull> clever: I wonder if that's intentional on part of the people that standardised the cdrom filesystem then
03:41:56 <doug16k> 650MB felt like almost infinite space back then, thankfully they blew a bit of space at the start for tricks like this
03:44:33 <doug16k> nowadays, 4.3GB DVDs feel small. even 25GB blu rays are small now
03:45:33 --- join: quc (~quc@host-89-230-167-225.dynamic.mm.pl) joined #osdev
03:46:34 <klange> CD-ROM was first demonstrated in 1984, at a time when portable storage was either 1.44M floppies or slow-seek tapes that still didn't touch that.
03:50:47 <doug16k> I had a 2x burner way back when they were brand new. that thing was mind blowing. you could put a scrached-to-hell disc in it and it read everything perfectly. you could bet your life that every byte it wrote would be readable years later
03:51:11 --- quit: Guest4630 (Remote host closed the connection)
03:51:17 <doug16k> now disc manufacturers are less afraid and they push it to the furthest that they can get away with
03:51:38 <klange> you can, generally, turn it down
03:51:47 <klange> I typically burn much slower than max speed when I still burn things
03:51:51 <klange> it's been a few years though
03:52:02 <klange> back in the days when that was how you got Linux distros set up
03:52:13 <klange> post bunch-o-floppies, but pre reasonably sized USB sticks
03:52:55 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
03:53:25 <jjuran> I still have my Debian netinst CDs :-)
03:59:47 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
04:02:12 --- quit: trout (Ping timeout: 240 seconds)
04:09:28 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
04:15:22 --- quit: salek__ (Ping timeout: 265 seconds)
04:16:22 --- join: korans (~korans@93.191.203.83) joined #osdev
04:18:31 --- join: Kimundi_ (~Kimundi@i577A9952.versanet.de) joined #osdev
04:18:49 --- quit: nwm (Ping timeout: 268 seconds)
04:20:51 --- quit: immibis (Ping timeout: 244 seconds)
04:21:21 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
04:22:19 --- quit: Kimundi__ (Ping timeout: 264 seconds)
04:22:39 <klange> My thought at the moment is to add entries for all the files on the fat image to the CD - then I don't need to do anything interesting, just update the extents and sizes.
04:22:56 <klange> That's a quick in-place edit.
04:28:42 <heat> This may be a stupid question, but why don't you store all your needed files(at least for boot) in the FAT partition?
04:28:48 <heat> Would save you a lot of work
04:29:20 <klange> because then I need a FAT driver to load them in the other bootloader *in addition* to needing to an ISO9660 one to find them in the first place?
04:29:40 <klange> if I were just build an EFI CD, that would probably fine
04:31:36 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
04:31:57 <heat> ah
04:32:28 <heat> I would just use a separate partition + gpt
04:32:54 --- quit: Humble (Quit: Leaving)
04:33:05 <klange> but then you're duplicating the files...
04:33:05 --- join: Humble (~hchiramm@2405:204:d301:618b:fb2f:f555:5f79:e5a4) joined #osdev
04:33:12 <klange> the idea is that both filesystems point to the same file data
04:33:16 --- join: myvar (~myvar@105.186.168.30) joined #osdev
04:33:28 <klange> doing otherwise would roughly double the size of the CD
04:33:34 <heat> duplicating which files?
04:33:48 <klange> kernel? modules? ramdisk?
04:33:51 <klange> ramdisk especially
04:34:05 <heat> if the bootloader in the efi partition knows that the files are at (gpt, part1) or something, you don't dupe a thing
04:34:16 <heat> you just have to add a filesystem driver for part1
04:34:19 --- quit: CheckDavid (Quit: Connection closed for inactivity)
04:34:44 <klange> I'm not sure what you think you're saying.
04:34:50 --- quit: variable (Ping timeout: 255 seconds)
04:36:35 <heat> My idea was to store the kernel, modules, ramdisk, etc in a separate partition. Your BIOS bootloader and your EFI bootloader both know how to access it, and you don't duplicate data
04:36:46 <klange> I have an ISO driver. I don't have a FAT32 driver. I can't legally implement a FAT32 driver. I want a CD with a kernel, modules, ramdisk, and I want to be able to boot it from BIOS and from EFI.
04:37:18 <myvar> if im not mistake its legal to do fat32 you may just not use long names yes ?
04:37:22 <heat> You can't legally implement a FAT32 driver?
04:37:41 <klange> You can not legally implement a compliant fat32 driver, you have to break it by design.
04:37:51 <heat> Pretty sure you can even use long names
04:38:26 <heat> What do you mean with "break it"?
04:39:21 <klange> You can either implement long names, or implement short names, but you can not implement both, and even then, just having FAT at all is a nightmare of legal trouble regardless, and embedded systems manufacturers are constantly harrassed by Microsoft for shipping anything with fat support that didn't pay a license.
04:39:26 <klange> It's not worth dealing with.
04:40:30 --- join: w17t (~w17t@unaffiliated/w17t) joined #osdev
04:40:57 <klange> So option 1 is put all the files in the ISO filesystem - that's what I have now. The BIOS loader can find them and has a rudimentary driver to read files. It works. the EFI loader currently does the same thing, but it speaks ATAPI directly - I want to move it to the appropriate EFI interfaces, so there's this challenge of going from a binary stored in an EFI system partition back to the ISO filesystem that i
04:41:03 <klange> s on the rest of that CD.
04:41:20 <klange> It's really easy to get files from the system partition, though.
04:42:33 <klange> EFI requires a FAT implementation of its own as part of the spec. Both FAT and ISO9660 store entire files with an offset and a length, so we can abuse that to make shadow files on the ISO 9660 that point to files in the FAT, or vice-versa, and it will work. This is a pretty classic "iso hybrid".
04:42:43 --- quit: drakonis__ (Ping timeout: 264 seconds)
04:42:43 <myvar> https://askubuntu.com/questions/516088/how-does-ubuntu-get-away-with-reading-fat32
04:42:45 <bslsk05> ​askubuntu.com: How does Ubuntu get away with reading FAT32 - Ask Ubuntu
04:42:52 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-zffmvqihxbbrdbat) joined #osdev
04:43:01 <myvar> exFAT = legal trubles
04:43:08 <myvar> FAT (eg FAT32 + VFAT) = fine
04:43:21 <klange> No, FAT = coerced license fees
04:43:39 <klange> exFAT = more clear legal standing for Microsoft
04:44:32 <klange> Technically, even the troubling parts of FAT (and exFAT) are only relevant to write-capable implementations.
04:44:41 <klange> But you're missing the bigger picture: This is cool.
04:44:55 <klange> You think I stuck an ISO in a PDF because it was a practical thing to do?
04:45:18 <myvar> i joind a bit late in the convertation
04:45:39 <myvar> so i dont have the full context
04:46:06 <klange> 5 minutes ago I posted the full context for reference.
04:46:30 <klange> Just putting stuff in the FAT would work, but I'd have to write a brand new BIOS bootloader.
04:46:49 <klange> With FAT support, on top of ISO support - probably - though maybe a GPT would obviate that.
04:47:14 <klange> The ISO hybrid approach has historical precedent, so it's not completely silly.
04:57:27 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
05:03:42 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:06:51 --- quit: trout (Ping timeout: 245 seconds)
05:07:52 --- quit: froggey (Ping timeout: 244 seconds)
05:09:44 --- join: froggey (~froggey@unaffiliated/froggey) joined #osdev
05:15:48 --- quit: Peetz0r (Read error: Connection reset by peer)
05:16:55 --- join: Peetz0r (~Peetz0r@2a02:58:4a:4c00:baae:edff:fe7d:3469) joined #osdev
05:26:27 <doug16k> I remember reading somewhere that microsoft grants unlimited permission to make a FAT32 LFN implementation as long as it is restricted to 32 character filenames
05:27:15 <doug16k> I wish I had the citation though
05:28:11 <doug16k> that's from what, pre 1995? they can't hold on to it forever
05:29:41 <doug16k> you have no choice but to use FAT to implement EFI. how can they legally hold a monopoly on being able to boot?
05:30:10 <doug16k> shaky ground to say the least
05:33:10 --- join: dijksterhuis (~dijksterh@188.29.165.20.threembb.co.uk) joined #osdev
05:33:22 --- quit: dijksterhuis (Client Quit)
05:33:50 --- join: glauxosdever (~alex@80.107.168.7) joined #osdev
05:36:16 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
05:36:19 <doug16k> FAT is utterly asinine anyway. entire filesystem is based on singly linked lists
05:37:45 <doug16k> you cannot make it worse than singly linked lists
05:38:23 --- join: HZun (~HZun@0x3ec72d49.osd.customer.dk.telia.net) joined #osdev
05:39:00 <doug16k> ok, maybe commodore 64 filesystem was a tad worse - it stored the next sector link in the 1st 2 bytes of every sector, and the allocation table was a bitmap
05:39:12 --- quit: variable (Ping timeout: 240 seconds)
05:39:26 <doug16k> but that system has zero memory overhead and for sequential reads it's optimal
05:39:35 <heat> ext2 also uses bitmaps for allocation
05:39:43 <heat> and ext3 and maybe ext4
05:40:38 <doug16k> commodore 64 did have "relative" files, which are analogous to the way ext4 represents ranges of a file, but limited to a single level IIRC
05:40:49 <doug16k> so even that was better than FAT
05:41:05 <doug16k> er, ext < 4 I mean
05:41:08 <doug16k> ext4 has extents
05:41:40 --- join: macdonag2 (~macdonag2@82-132-228-112.dab.02.net) joined #osdev
05:43:03 <doug16k> maybe I should implement commodore 64 filesystem, lol
05:43:12 <doug16k> would be faster than fat
05:44:09 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
05:44:34 <doug16k> in practice though it would suck for DMA. the sector links being in the 1st 2 bytes of sequential file sectors
05:45:18 <heat> you don't do DMA directly to user space buffers anyway
05:45:44 <doug16k> yeah but the problem with it is, you don't know where sector N+1 is until you read sector N
05:45:48 <klange> you might if you're trying to do zero-copy...
05:49:52 <heat> oh right
05:49:53 <heat> splice
05:50:30 <heat> well, the concept of it anyway
05:51:44 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-ygvawqtvafsgevvc) joined #osdev
05:51:54 <myvar> while we are on the topic of worst file systems, i think the worst posible file system is where you generate a databace of every posible permutation of bytes, then every file is is an index for that databace #memes
05:52:24 <klange> have you heard of pifs?
05:52:53 <heat> what if
05:53:13 <heat> I made a filesystem with the metadata as JSON
05:53:49 <klange> what if instead of a filesystem, I just had a big block of json
05:54:04 <heat> yes
05:54:09 <heat> just
05:54:09 <myvar> Json as in a string, or binary vertion ?
05:54:10 <heat> yes
05:54:13 <heat> string
05:54:14 <heat> obv
05:54:16 <myvar> fml
05:54:21 <heat> we need to be portable here
05:54:25 <klange> superblock? just a json object; directory? json object with a list! of what? json objects representing files
05:54:30 <klange> the file data? that's just a big JSON string
05:54:37 <myvar> sounds like mongo db xD
05:54:59 <klange> "but how would you write to it?" same way you write to any JSON file, from scratch each time
05:55:25 <heat> then the driver would use nodejs
05:55:38 <heat> absofuckinglutely flawless
05:55:49 <myvar> i crindging so hard rn
05:55:54 <klange> actually JSON may be an acceptable format for a ramdisk - arbitrary new metadata, parser isn't too complicated, file size shouldn't be a problem with compression...
05:56:42 <myvar> https://en.wikipedia.org/wiki/BSON
05:56:42 <bslsk05> ​en.wikipedia.org: BSON - Wikipedia
05:56:50 <myvar> maby bson but not as a string
05:57:24 <heat> "Dahl was inspired to create Node.js after seeing a file upload progress bar on Flickr. The browser did not know how much of the file had been uploaded and had to query the Web server."
05:57:26 <heat> really
05:57:27 <heat> like
05:57:38 <heat> that's your whole motivation behind node
05:57:53 <myvar> lol
05:58:07 <myvar> intresting idea is to create an operating system that is puerly a jit
05:58:19 <myvar> jit = reflections posible
05:58:39 <heat> yes
05:58:42 <heat> pure node.js
05:58:44 <myvar> that way you can create an os that can only run a jit laguage like C# for eg, but serlization is practical becuase of reflections
05:58:47 <heat> I like that
05:59:12 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
05:59:17 <myvar> node.js os seems like a terible idea javascript should be deleted from the history of man kind
05:59:53 <myvar> if eather of use ever invent a time machien we should pledge to go back in time and stop js from happening
06:00:47 <doug16k> js is good. anyone that hates js doesn't know js. it's almost perfect for asynchronous code
06:01:02 <heat> node.js is perfect
06:01:17 <doug16k> the only language other than js that has closures that are anywhere near as natural is lua
06:01:19 <heat> also
06:01:22 <heat> https://forum.osdev.org/viewtopic.php?f=2&t=28159
06:01:23 <bslsk05> ​forum.osdev.org: OSDev.org • View topic - runtime.js
06:01:31 --- join: Nach0z (~nach0z@c-98-192-72-54.hsd1.ga.comcast.net) joined #osdev
06:01:32 --- quit: Nach0z (Changing host)
06:01:32 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
06:01:39 <heat> runs the V8 js engine in bare-metal
06:02:13 --- quit: xenos1984 (Remote host closed the connection)
06:02:33 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
06:02:48 <myvar> i whould rather run a JIT runtime insted of flat out interpeting that way the os is a lot more light wait and the runtime is serperated, and is therefore not laguage spesific so you can use any laguage that targets your jit
06:03:11 <myvar> and Jit give most of the advantages of an interpited laguage
06:03:22 <myvar> (fyi im dyslexsic so spelling is horible)
06:03:24 --- quit: mniip (Read error: Connection reset by peer)
06:03:28 <doug16k> js is jit compiled
06:04:15 <doug16k> lua is too, if you use luaJIT. the only thing that sucks about lua though is it has 1-based array subscripts. I can't stand that
06:04:24 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
06:04:43 <myvar> same 0 = life
06:04:51 <klange> well, see, the situation in lua is complicated
06:04:51 --- join: mniip (mniip@freenode/staff/mniip) joined #osdev
06:04:58 <klange> because lua doesn't really understand arrays...
06:05:13 <klange> it has associated arrays that by default use 1 as their first index
06:05:15 --- quit: mniip (Remote host closed the connection)
06:05:15 <myvar> i see js is interpited, when i learnd javascript it was not as far as a iknow im i just old, or did i miss the hole jit part ?
06:05:17 <klange> associative*
06:05:55 <doug16k> myvar, every browser uses a jit engine, node uses chrome's V8 jit engine. in ancient history, yes, it was interpreted in netscape navigator
06:06:13 <myvar> ok wll im not that old
06:06:14 <klange> aka the good old days
06:06:18 <myvar> so i just missed that part
06:06:25 --- join: mniip (mniip@freenode/staff/mniip) joined #osdev
06:07:43 <myvar> i think my real problem with js is the fact that every pardime you use is self imposed, if you want to make an object there are literly 3 ways of making oop style objects
06:07:49 <myvar> i like consitancey and order
06:07:52 <doug16k> myvar, I made a wolfenstein clone in js, using 3d css. every wall face was a div. it uses matrix3d transforms to transform them using a 4x3 matrix stack. runs at realtime speed.
06:08:05 <myvar> lol
06:08:10 <doug16k> but you can look up and down, so superior to wolfenstein
06:08:14 <heat> ew
06:08:20 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
06:08:51 <doug16k> it was mostly for a laugh
06:09:09 <klange> should have remade quake instead
06:09:13 <myvar> one whould hope it was for jokes, ...
06:09:15 <klange> every face as a div
06:10:04 <myvar> how did we go from, fat32 to using html and css as a rendering system
06:10:11 <doug16k> klange, doable, but irregularly shaped sectors would be problematic. I suppose with sufficiently sophisticated skewing transforms it is possible
06:10:37 <myvar> did you use z buffer or portal rendering ?
06:10:49 <doug16k> z buffer
06:10:51 <myvar> ah
06:10:59 <doug16k> simple painter's algorithm
06:11:04 <myvar> i see
06:11:08 --- quit: trout (Ping timeout: 255 seconds)
06:11:10 <doug16k> had to reorder the divs in the dom
06:11:37 <doug16k> and the z buffer helped for the last bit of edge cases
06:11:46 <myvar> yea
06:12:36 <doug16k> point of bringing it up was that js code can be fast :)
06:13:20 <myvar> well, i never denied that it cant be fast, i have a problem with the laguage it self its design
06:15:52 <doug16k> here it is: https://tinyurl.com/yby3q4nf
06:16:00 <doug16k> there's an integrated map editor :)
06:16:38 <doug16k> I was going to make it do bsp sort but never got around to it
06:16:57 <klange> you're exactly the kind of mad man who should go write an HTML rendering engine yourself
06:17:08 <klange> preferrably with minimal dependencies so I can port it to my OS
06:17:21 <heat> doug16k: NET::ERR_CERT_DATE_INVALID
06:17:24 <heat> you should fix it :)
06:17:49 <doug16k> yeah I bought the cert and everything. too lazy to set it up
06:18:25 <doug16k> it's mouselook/WASD interface if you click the viewport
06:18:28 <geist> ahyeah i need to do the same. where did you buy it from?
06:18:30 <geist> the cert that is
06:18:42 <olsner> klange: if Opera had GPL:d their code after the leak, that'd be a nice minimal-dependencies web browser
06:18:46 <doug16k> namecheap
06:18:57 <doug16k> their prices are good and their support is excellent
06:19:05 <olsner> but somewhat out of date with the current web by now
06:20:09 <geist> kk
06:20:12 --- join: dijksterhuis (~dijksterh@188.29.165.20.threembb.co.uk) joined #osdev
06:20:22 <heat> port chromium
06:20:25 <heat> ez
06:20:30 --- quit: macdonag2 (Quit: macdonag2)
06:20:50 <doug16k> heat, yeah, if you want to implement every single nook and cranny of IPC and shared memory APIs
06:21:16 <heat> wouldn't mind tbh
06:21:20 <heat> IPC and shared memory is fun
06:22:35 --- quit: dijksterhuis (Client Quit)
06:23:03 <klange> olsner: I highly doubt it, probably so deeply embedded in the libraries of the platforms it was ported to it'd never come out in tact.
06:23:11 --- join: prokbird (~shams@117.205.129.196) joined #osdev
06:23:48 <klange> heat: good luck porting blink to anything that has been through three rounds of certification and at least two decades of development
06:23:53 <klange> hasn't been*
06:24:25 <klange> pretty sure that wants a full GL stack just to render a text file at this point
06:24:49 --- quit: ratschance (Remote host closed the connection)
06:25:09 <heat> what's so hard about blink?
06:25:16 --- join: ratschance (~ratschanc@205.175.226.102) joined #osdev
06:25:19 <klange> doug16k, geist: I feel like I should ask "Why not Let's Encrypt?"
06:25:43 --- join: Vulcan_ (~Vulcan@80.215.75.221) joined #osdev
06:25:52 <doug16k> because it costs almost nothing to buy a cert
06:26:06 <klange> heat: All modern engines are essentially OSes in their own right and demand significant system support. None of them are self-contained. The list of libraries required to build Blink or Webkit is immense.
06:28:10 <heat> i mean
06:28:18 <heat> probably depends on the system itself
06:28:52 <heat> I imagine the harder things to port should be windowing/gl stuff
06:28:58 <heat> because the rest shouldn't be too hard
06:29:28 <klange> It's mostly the network stack.
06:29:35 <heat> really?
06:29:45 <klange> But the rendering stacks are still a massive challenge.
06:29:57 <klange> They are heavily integrated into the system graphics libraries that they have been ported to.
06:30:07 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:30:20 <graphitemaster> porting a webbrowser, other than netsurf is so incredibly complex due to the amount of system support they rely on, you're looking at implement a full stack desktop before you even get there
06:31:34 <graphitemaster> something like chrome or firefox is already going to demand full GL, dbus (or similar), freetype (system native) via skia (which also wants fontconfig and the font-config file layout), to name a few
06:31:42 <doug16k> have you seen the comparison of linux and chrome? chrome is almost the same line count as linux including every driver
06:32:02 <heat> tianocore is bigger though
06:32:05 <doug16k> with that ridiculous amount of code, they'll probably be touching almost every API imaginable
06:32:42 --- quit: NaNkeen (Ping timeout: 240 seconds)
06:32:47 <graphitemaster> chrome is an OS
06:32:56 <graphitemaster> it does everything an OS does
06:33:04 --- quit: SopaXorzTaker (Remote host closed the connection)
06:33:05 <graphitemaster> it just needs a lot of OS support to run
06:34:50 <klange> It's possible an ancient Gecko might prove workable.
06:34:53 <heat> oh wtf
06:35:06 <heat> I tried strace -c -f on chromium
06:35:22 <heat> crashed because the setuid sandbox isn't running as root
06:35:30 <graphitemaster> yeah, that too
06:35:44 <graphitemaster> chromium has a setuid sandbox that it runs tabs under
06:35:54 <graphitemaster> it's setuid because it uses seccomp syscall filtering
06:36:03 <doug16k> that's the IPC nightmare I mentioned. it's heavily multi-process
06:36:11 <graphitemaster> to isolate the system calls the tab is allowed to call
06:36:18 <clever> graphitemaster: by default, linux allows the sandboxing to be done by any user
06:36:20 <graphitemaster> this was more for when they had nacl plugins
06:36:22 <heat> doug16k: that was because of ptrace though
06:36:31 <clever> graphitemaster: but patch sets like grsecurity restrict the sandboxing to root, and need the setuid wrapper
06:36:47 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
06:36:50 <graphitemaster> clever, the problem with any user sandboxing is then that user can change the sandboxing permissions too
06:36:53 <graphitemaster> thus escaping the sandbox
06:36:59 <graphitemaster> unless it's set once only
06:37:03 <graphitemaster> which is still easy to work around
06:37:19 --- quit: w17t (Read error: Connection reset by peer)
06:37:19 <graphitemaster> any user sandboxing is fundamentally broken
06:37:25 <clever> graphitemaster: what if the syscall filter simply didnt allow the syscall requiered for changing the filter?
06:37:45 --- quit: Vulcan_ (Remote host closed the connection)
06:37:57 <heat> what if the tab legitimately needs to change the filter?
06:38:16 <clever> what need would it have to change the filter?
06:38:24 <graphitemaster> clever, depending on which syscalls are allowed, you can still launch processes rewrite binaries, etc so the next run it doesn't filter it out
06:38:31 <clever> and it could just use IPC to ask a more privledged process to do the action
06:38:48 <heat> idk, I never used seccomp syscall filtering
06:38:55 <heat> but there's certainly a good reason why
06:39:08 <graphitemaster> it's also completely unnecessary now because no plugins for chrome are native code anymore
06:39:14 <graphitemaster> except the webdrm stuff
06:39:30 <clever> graphitemaster: pretty sure chrome always ran the native plugins in its own process, seperate from the rendering sandboxes
06:39:55 <olsner> it's also supposed to protect against bugs, e.g. if javascript or an image exploits a chrome bug it will not do any damage except crash a sandboxed process
06:39:59 <graphitemaster> chrome is a fractal of bad engineering, typical of Google.
06:40:10 <olsner> unless you couple it with a second exploit for the sandbox
06:40:17 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
06:40:36 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
06:41:42 --- quit: NaNkeen (Ping timeout: 240 seconds)
06:41:49 <graphitemaster> I like to think Chrome's approach is the epitome of security through obscurity because none of these things actually prevent the class of exploits that plague the web. They're more "what if" scenarios that while happen aren't as common as you think, and even if they were, this security mechanism tends to fail even still. Their motto for security is literally "make it harder" not "make it impossible" and I'm sorry but making
06:41:49 <graphitemaster> something harder to exploit isn't security.
06:42:32 <klange> unrelated, this is the smallest OTC adapter I have ever seen https://twitter.com/kouchan66/status/1016286943410208768
06:42:33 <bslsk05> ​twitter: <kouchan66> USBのオス・メスをダイレクトに変換できて結構優れものかも知れない😊 https://pbs.twimg.com/media/DhqTjHWU8AAnav5.jpg https://pbs.twimg.com/media/DhqTj1iUYAEFKvA.jpg https://pbs.twimg.com/media/DhqTkchUEAID_6T.jpg https://pbs.twimg.com/media/DhqTlG8UYAACZPi.jpg
06:42:34 <heat> it's very hard to make things impossible though
06:42:52 <graphitemaster> heat, I would start with not making something possible to begin with
06:43:06 --- quit: variable (Ping timeout: 245 seconds)
06:43:59 --- join: Vulcan_ (~Vulcan@80.215.75.221) joined #osdev
06:44:45 <graphitemaster> The problem with the web is that it has too large of a surface area for attacks because of poorly thought out APIs created by hipsters who have zero knowledge about security and are only concerned with standardizing some new hip feature they really badly want because they have a vetted interest in it for their new app or startup
06:45:24 <graphitemaster> these people are not industry leaders, they're young bumbling idiots hell bent on making a quick buck
06:48:18 <heat> what if we ran chromium in a container
06:48:21 <heat> effectively safe?
06:48:22 <graphitemaster> The web needs a better standards body where there's actual push back on features
06:48:40 <graphitemaster> and some discussion on deprecating and removing a lot of cruft
06:48:44 <heat> unless it somehow took over the kernel
06:48:50 <graphitemaster> and more focus on security and stability
06:49:46 <klange> containers aren't safe - they're not a security mechanism
06:49:58 <heat> what are they then?
06:49:59 <klange> they're a deployment tool
06:50:29 <klange> packaged, self-contained userspace so you can not worry about path conflicts, network interface oddities, etc.
06:50:45 <rain1> but they're a little safe though?
06:50:45 <graphitemaster> here's what is safe, grabbing yourself a box, plugging it into the internet and deploying an entire in memory stack for it every time it's called on, then wiping it clean
06:50:49 <heat> but it's still safer
06:50:58 <doug16k> want to kill chrome? enter this in the console: while (true); that's it, it's hung. if you go to sources tab and press break it just goes disabled and is stuck in the infinite loop
06:51:11 <graphitemaster> it's not even safe to use other providers systems like Amazon (EC2) Google (AppEngine) or Microsoft (Azure) platforms
06:51:46 <doug16k> think you can just close the tab? nope
06:52:00 <graphitemaster> The fact Javascript even has a forever loop
06:52:54 <graphitemaster> go work for cloud flare, drop a while(true); into their CDN cached jquery, watch 80% of the entire internet go broke for a month because the browser caching policy is also broken
06:53:58 <graphitemaster> the fact that is possible is because three things are broken (the concept of CDNs, the fact everyone always uses CDNs), the fact every website uses heaps of JS, the fact browser caching is broken, etc, etc
06:54:21 <graphitemaster> and well the fact JS lets you do that and browsers have no TDR or something to prevent it
06:54:49 <graphitemaster> firefox at least has "this script is unresponsive, would you like to kill it" but you can't click the damn window because the while(true) locks up the UI
06:54:59 <klange> computers, ultimately, were a mistake
06:55:01 <doug16k> I hate CDNs. just a brainwashing campaign where they convinced everyone that a cache hit of a script is going to be significant enough. what it really does is hand over user tracking referrer links to the CDN provider
06:55:48 <graphitemaster> I build firefox nightlies from source with a patch that prevents it from ever assembling a HTTP header with a Refer field
06:56:16 <graphitemaster> *Referer
06:56:31 <doug16k> it always amuses me when developers think they will have better performance by doing a certain magic thing, then in their code they cause a massive number of reflows and generally piss away resources
06:56:34 <graphitemaster> https is supposed to prevent it from being sent anyways
06:57:12 --- quit: HZun (Quit: Leaving)
06:57:29 <graphitemaster> want your website to load fast, avoid heaps of JS, I know that's hard, avoid loading a lot of crap on the page at once (use ajax to load shit on demand if need be, but write it yourself, don't use jquery...)
06:57:36 --- quit: ratschance (Remote host closed the connection)
06:57:44 <graphitemaster> and that's really all there is to it
06:58:04 <graphitemaster> and configure your server to gzip everything, and reuse sessions
06:58:50 <graphitemaster> and maybe avoid the shitty httpd's that are slow because the people writing them are more concerned with how many active connections it can handle at once instead of how fast it can deliver or render a page if there's server side rendering
06:59:13 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:59:36 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
07:02:35 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
07:05:17 <heat> non-osdev question, but how hard is it to make a fast real-time gaussian blur?
07:06:08 <heat> 1) I would love to use it in my windowing system
07:06:12 <heat> 2) Valve fucked up
07:06:23 <klange> real-time gaussian is hard
07:06:41 <klange> at modern resolutions, on a CPU, impossible
07:06:51 <heat> with a gpu though?
07:07:00 <klange> even with a GPU I'd say do a couple of box blurs
07:07:25 <klange> but graphitemaster is a resident graphics guy, might have different ideas
07:07:31 <graphitemaster> Gaussian is separable (which means it can be done horizontally and then vertically) quite fast, and because the hardware already does bilinear filtering, you can exploit that for the separability layer, so it can be made even faster
07:07:40 <graphitemaster> we do realtime gaussian for a lot of things in games
07:07:50 <graphitemaster> mostly fixing shader aliasing in stuff like ssao
07:07:55 --- quit: Vulcan_ (Remote host closed the connection)
07:08:05 <graphitemaster> but also for depth of field effects and motion blur
07:08:12 <graphitemaster> box blurs are faster tho
07:08:21 <heat> in the new UI update valve made a blur that halves people's fps
07:09:03 <heat> when they start stacking up the blurs, it gets worse
07:09:29 <heat> maybe they screwed it up because it definitely feels unoptimized
07:09:32 <graphitemaster> that's because you should never stack blurs, that's the cheap way to do blurs
07:09:39 <graphitemaster> cheap for programming
07:09:54 <graphitemaster> if you need a certain blur radius, you program for that radius
07:10:14 <graphitemaster> because the more passes you do the more fill rate and alu you're doing over all
07:10:18 <graphitemaster> it grows n^2
07:10:19 --- quit: myvar (Ping timeout: 244 seconds)
07:10:26 <graphitemaster> opposed to just n
07:11:20 <graphitemaster> you can also do blurs temporally if you don't need temporal stability
07:11:36 <graphitemaster> the first couple frames may look bad
07:12:05 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
07:12:24 <graphitemaster> temporal stability is probably a requirement for a UI tho :P
07:15:15 <graphitemaster> if you want to read more into the specifics for hwo to do it well on a GPU, (programing for each set of taps and radii) http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/
07:15:19 <bslsk05> ​rastergrid.com: Efficient Gaussian blur with linear sampling
07:15:25 <graphitemaster> this also exploits the sampling hardware
07:15:56 --- quit: trout (Ping timeout: 276 seconds)
07:17:13 <graphitemaster> the big save is just doing it separably tho
07:17:22 <graphitemaster> that should be enough to make it fast even on CPUs
07:20:40 <graphitemaster> if you have compute shaders, the faster more clever way is to use a handful of specialized box blurs by doing horizontal and vertical separately, except you scan each strip and maintain a running total, adding the pixel radius/2 in front while subtracting pixel radius/2 behind and multiplying out 1/radius to that running average
07:21:16 <graphitemaster> and by handful I mean somewhere from 3 to 5, because it looks gust as good as a gaussian
07:23:57 <graphitemaster> problem with that approach is it does not map well to GPU hardware pre compute era
07:24:44 <graphitemaster> the slow part of guassian in typical shaders is the texture sampling itself (taps), and you want to reduce that as much as possible, not so much the ALU aspect
07:24:55 --- quit: andrei-n_ (Quit: Leaving)
07:25:35 <graphitemaster> and it turns out, there's very little difference between several boxes and one guassian when implemented correctly in terms of performance in the typical shading route because they end up doing the same # of taps
07:25:49 --- quit: Nach0z (Ping timeout: 244 seconds)
07:27:38 --- join: Nach0z (~nach0z@c-98-192-72-54.hsd1.ga.comcast.net) joined #osdev
07:27:38 --- quit: Nach0z (Changing host)
07:27:38 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
07:28:15 --- quit: pie__ (Read error: Connection reset by peer)
07:28:21 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
07:30:22 <geist> graphitemaster: word.
07:31:52 --- quit: brynet (Remote host closed the connection)
07:33:17 --- join: hmmmm (~sdfgsf@pool-72-79-169-12.sctnpa.east.verizon.net) joined #osdev
07:44:16 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
07:45:17 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
07:47:04 --- quit: variable (Ping timeout: 265 seconds)
07:50:30 --- quit: zopsi (Quit: Oops)
07:51:06 <doug16k> I broke my module loader. now I'm going over the relocations and I'm finding that the elf documentation actually doesn't make sense. for example, S + A - P... the symbol (S) won't have the base address of the module included, and addend certainly won't, so subtracting P makes it lightyears negative
07:51:12 --- quit: NaNkeen (Ping timeout: 240 seconds)
07:51:45 <doug16k> they mean P relative to the module load address?
07:51:54 <doug16k> P is the place where you are doing the relocation
07:52:40 --- join: zopsi (~zopsi@dir.ac) joined #osdev
07:53:31 --- quit: jack_rabbit (Ping timeout: 264 seconds)
07:54:02 <heat> which relocation type is that?
07:54:05 <doug16k> the relocation docs are borderline nonsense. it neglects to mention what to do if you did or didn't do a symbol lookup
07:54:08 <doug16k> PC32
07:54:39 <doug16k> when is it the symbol value and when is it the section base?
07:54:59 <heat> P should be the pc
07:55:04 <heat> S is the symbol value
07:55:15 <heat> and A is the addend
07:55:22 <heat> I don't see what your problem is
07:55:23 <doug16k> ya but P technically is something like 0xFFFFFFFF800C0016
07:55:57 <heat> you have to patch the symbol value
07:56:21 <doug16k> which makes sense when you are dynamically linking to something external, like the printk in the kernel. makes no sense when it is just relative to a section base in the module
07:56:28 --- join: flacks (~jean@184.91.69.131) joined #osdev
07:56:58 <heat> no
07:57:08 <heat> when you're linking to something external, you don't patch the symbol value
07:57:22 <heat> when you're linking to your own symbols, you have to patch it
07:57:32 <doug16k> PLT32 is working fine. calls are working correctly
07:57:43 <doug16k> it's PC32 for something within the module that is giving me trouble
07:58:31 <heat> are you adding the module's base in the symbol's value?
07:58:36 <doug16k> I'll try to give a concrete example. 1 sec
08:00:32 <doug16k> ok, so it's S + A - P... S=0, A=-8, P=FFFFFFFF800e9006. 0+-8+FFFFFFFF800e9006 = nonsense
08:00:58 <doug16k> is it because I also have to look at shndx in the symbol and add its base address + module load address?
08:01:09 <heat> yes
08:01:20 <heat> probably, that is
08:01:26 <heat> it definitely sounds like it
08:02:02 --- quit: matryoshka (Quit: Leaving)
08:02:12 <doug16k> k thanks, let me try that
08:02:42 <heat> e.g: 0xFFFFFFFF80400000 - 8 - 0xFFFFFFFF800e9006=0x316ff2, seems valid
08:02:55 <doug16k> yes that would be sensible
08:04:01 <doug16k> the S=0 makes sense because that happens to be the very first variable in .bss in my little test case module. neglecting to add the bss base would explain my issue
08:05:29 --- nick: az0r -> zeroSignal
08:05:30 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
08:07:38 <doug16k> that worked. would be nice if it mentioned that "S" really means lookup base of section referred to in sym->sh_ndx AND add the symbol value
08:07:53 <doug16k> it's one of those things that an author will think is so obvious that they need not mention it
08:08:05 <doug16k> which is bad technical writing
08:08:45 <doug16k> nothing is too obvious in technical writing. say everything
08:10:20 --- quit: manzerbredes (Quit: WeeChat 2.1)
08:14:37 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:14:54 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
08:15:07 --- quit: pie_ (Remote host closed the connection)
08:15:21 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
08:17:41 --- join: drakonis__ (~drakonis@unaffiliated/drakonis) joined #osdev
08:18:20 --- quit: trout (Ping timeout: 276 seconds)
08:21:07 --- quit: drakonis (Ping timeout: 264 seconds)
08:24:32 --- quit: m_t (Quit: Leaving)
08:29:58 --- quit: X-Scale (Ping timeout: 248 seconds)
08:30:36 --- join: isaac_ (~isaac@host81-129-159-55.range81-129.btcentralplus.com) joined #osdev
08:31:14 --- nick: isaac_ -> isaacwoods
08:31:21 --- join: X-Scale (~ARM@83.223.226.153) joined #osdev
08:32:47 --- quit: grouse (Quit: Leaving)
08:35:32 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
08:35:51 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
08:36:08 --- join: [X-Scale] (~ARM@83.223.242.197) joined #osdev
08:37:38 --- quit: X-Scale (Ping timeout: 244 seconds)
08:37:41 --- nick: [X-Scale] -> X-Scale
08:43:48 --- quit: [WildCard] (Quit: If you are sad in your skin, don't apologies to make me sad.)
08:44:13 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:44:29 --- quit: graphene (Remote host closed the connection)
08:44:41 --- join: [Nightmare] (~while@62-210-114-224.rev.poneytelecom.eu) joined #osdev
08:44:46 --- quit: [Nightmare] (Changing host)
08:44:46 --- join: [Nightmare] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
08:45:59 --- join: graphene (~graphene@46.101.134.251) joined #osdev
08:46:03 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
08:47:09 --- quit: drakonis__ (Ping timeout: 256 seconds)
08:47:19 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
08:50:42 --- quit: variable (Ping timeout: 240 seconds)
08:56:02 <drakonis_> https://www.arm.com/-/media/global/company/arm-risc-v-infographic.png hahahahaha fuck off arm
08:56:06 <drakonis_> https://riscv-basics.com/
08:56:07 <bslsk05> ​riscv-basics.com: RISC Architecture: Understanding the Facts – Arm
08:57:41 --- join: m3nt4L (~asvos@2a02:587:a022:df00:3285:a9ff:fe8f:665d) joined #osdev
08:58:32 --- quit: prokbird (Ping timeout: 255 seconds)
09:03:13 <geist> hah
09:03:18 --- quit: promach_ (Ping timeout: 240 seconds)
09:10:53 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
09:13:17 --- quit: pie_ (Ping timeout: 244 seconds)
09:18:58 --- join: Tyrmolx (~yaaic@APN-123-252-49-gprs.simobil.net) joined #osdev
09:19:06 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:19:16 --- quit: Tyrmolx (Client Quit)
09:19:34 --- quit: zeus2 (Ping timeout: 248 seconds)
09:22:02 --- quit: trout (Ping timeout: 276 seconds)
09:22:41 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
09:28:47 --- quit: NaNkeen (Ping timeout: 244 seconds)
09:29:53 --- join: jakogut_ (~jakogut_@68.116.64.178) joined #osdev
09:30:56 --- quit: jakogut_ (Remote host closed the connection)
09:31:36 --- join: jakogut_ (~jakogut_@68.116.64.178) joined #osdev
09:36:11 --- quit: jakogut_ (Read error: Connection reset by peer)
09:37:46 --- quit: epony (Quit: QUIT)
09:40:11 --- quit: korans (Quit: Lost terminal)
09:41:08 --- quit: drakonis_ (Remote host closed the connection)
09:46:35 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
09:48:12 --- quit: drakonis (Ping timeout: 240 seconds)
09:48:15 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
09:48:45 <heat> do fs drivers usually have their own metadata structures or do they keep around the raw filesystem metadata?
09:48:58 <heat> (like a copy of it)
09:50:08 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
09:50:32 <heat> because the raw metadata is a bit hard to work with
09:51:31 --- quit: angel0xff (Ping timeout: 244 seconds)
09:52:18 <Love4Boobies> Do whatever you think is easier.
09:52:31 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:52:43 <izabera> yes this is what's always recommended
09:52:57 <izabera> do what you think is easier, instead of following the best practices
09:53:02 <izabera> great advice Love4Boobies
09:53:12 --- quit: variable (Ping timeout: 240 seconds)
09:53:39 --- join: jakogut_ (~jakogut_@68.116.64.178) joined #osdev
09:53:55 <Love4Boobies> You do understand that human conversations are context-sensitive, do you not?
09:54:19 <Love4Boobies> And the best practice is obviously to write whatever is most maintainable.
09:54:28 <Love4Boobies> Stop pretending to be intelligent, it can be embarrassing.
09:54:35 <rain1> stfu
09:55:24 <heat> why is everyone getting so aggressive
09:55:32 <sham1> Aaargh
09:55:40 <Love4Boobies> No one is being aggressive. I am being reasonable and izabera is being metally challenged.
09:55:43 --- quit: drakonis_ (Ping timeout: 256 seconds)
09:56:00 <heat> and rain1 said stfu
09:56:02 <izabera> that's ableist
09:57:04 <Love4Boobies> No it isn't.
09:57:37 <Love4Boobies> You have to somehow discriminate against someone who is disabled in order for it to be ableism.
09:58:12 --- quit: jakogut_ (Ping timeout: 240 seconds)
09:58:25 <Love4Boobies> If you observe that someone is black, does that make you a racist?
09:58:27 <bcos> heat: I'd expect VFS to cache half the metadata (e.g. directory info) and lower-level (e.g. storage device driver) to cache nothing; which implies that FS layer should cache whatever metadata VFS doesn't (e.g. info for tracking free blocks)
09:58:59 <izabera> Love4Boobies: using it as a slur is ableist
09:59:14 <heat> So, this is what I was thinking: I could either use the raw disk structures like I was doing: Advantages: May be a tiny bit faster if the other option is done wrong; Uses less memory; Disadvantages: Less maintainable
09:59:18 <bcos> heat: For an example; for FAT I'd expect FS layer to cache the "Cluster Allocation Table"
10:00:25 <heat> Or I could cache structures in the driver's memory: Advantages: May be a lot faster due to easier synchronization, buffer flushing, etc; More maintainable; Disadvantages: Uses more memory, may be really slow if done horribly
10:01:10 <bcos> Hrm - also for FAT12/16/32, I'd convert the raw (Cluster Allocation Table) data into generic 32-bit entries (partly to make it easier for the same code to support all variations)
10:01:26 <Love4Boobies> izabera, I disagree. If I say you're disabled, that has not barring not the disabled. I am merely stating that, as far as I am concerned, you suffer from a disability yourself. Unless associating anyone with yourself is an insult, in which case I may be persuaded.
10:01:43 <Love4Boobies> Ugh, who's disabled now?
10:01:49 <Love4Boobies> that has no barring on the*
10:01:52 <bcos> heat: Which structures?
10:01:53 <heat> I'm not sure if you're familiar with the ext2 inodes, but i.e I could cache the indirect blocks, add some caching mechanisms, etc
10:02:21 <heat> and/or register changes to a specific directory, that then get flushed by a thread
10:02:22 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
10:03:46 <heat> I believe it would help with locking and would ease maintainability and possibly help performance
10:05:26 <bcos> heat: For that case I'm not sure how converting the raw data into something else would improve performance or maintainability
10:06:45 <heat> For now I'm not caching hard drive writes/reads
10:07:10 <heat> adding that would let me cache writes/reads, would save me/ease lookups of blocks
10:07:13 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
10:07:16 <bcos> ..in other words; I'd cache "blocks containing raw inode data" at FS layer
10:07:18 <heat> would certainly make the code less cnfusing
10:07:58 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
10:08:00 <heat> bcos, what do you mean?
10:08:12 --- quit: drakonis (Ping timeout: 240 seconds)
10:09:02 <bcos> Each ext2 inode is stored on disk in a whole block?
10:09:35 <heat> no
10:09:45 <heat> inodes are smaller than blocks
10:09:59 <heat> they are stored in inode tables(which are stored in blocks)
10:10:02 <bcos> How big?
10:10:16 <bcos> Ah, OK - so you'd cache the raw inode table
10:10:50 <heat> they're usually ~128 bytes each
10:11:28 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
10:12:24 * bcos wonders if you can memory map the inode table - let kernel worry about cache management
10:12:42 --- quit: AverageJ0e (Ping timeout: 264 seconds)
10:13:04 <heat> I was also thinking of extending the caching method that regular files use
10:13:36 <heat> so that block devices could use something like it
10:14:06 --- join: salek__ (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
10:14:07 * bcos thinks block devices should never cache anything ever
10:14:22 <heat> then, the drivers could use the already existing mmap MAP_SHARED functionality to just write and forget
10:14:25 <heat> bcos, why?
10:14:29 <heat> It's faster
10:14:36 <bcos> No, it's slower
10:15:11 <bcos> If you assume that VFS caches normal file data and that it's silly to cache the same data in two or more places; then..
10:16:00 <heat> maybe the vfs cache could store multiple blocks of data
10:16:14 <heat> and the actual cache would be at the block level
10:17:25 <heat> so each vfs cache block would be a group of block-level cache blocks
10:18:34 <bcos> Let's assume you have several storage device drivers, with a partitioning scheme on top of that, with a RAID layer on top of that, with an encryption layer on top of that, with a file system layer on top of that. For reads, FS layer (and encryption layer, and RAID layer, and ...) is never used unless there's a "VFS cache miss" so all of that overhead never matters
10:19:12 <bcos> (or at least, all the overhead only matters when you need to transfer data from slow disk anyway)
10:22:21 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:24:20 --- quit: CheckDavid (Quit: Connection closed for inactivity)
10:24:38 --- quit: trout (Ping timeout: 265 seconds)
10:25:11 <bcos> Also note that VFS cache should cache pages (to make virtual memory management more efficient) not blocks
10:27:05 <heat> right
10:30:09 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
10:31:57 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:f102:7d72:18ac:ac9c) joined #osdev
10:39:26 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
10:41:44 --- quit: booyah (Ping timeout: 256 seconds)
10:43:24 --- join: pie___ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
10:46:42 --- quit: pie__ (Ping timeout: 268 seconds)
10:47:12 --- quit: MDude (Ping timeout: 240 seconds)
10:47:58 --- quit: JusticeEX (Ping timeout: 256 seconds)
10:49:00 --- join: mattc_ (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
10:50:43 --- quit: graphene (Remote host closed the connection)
10:51:50 --- quit: freakazoid0223 (Remote host closed the connection)
10:52:10 --- join: graphene (~graphene@46.101.134.251) joined #osdev
10:53:03 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
10:53:05 --- join: zeus1 (~zeus@154.226.106.180) joined #osdev
10:56:17 --- quit: variable (Ping timeout: 276 seconds)
10:56:24 --- join: prokbird (~shams@117.205.135.33) joined #osdev
10:58:14 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
11:06:40 <doug16k> bcos, yeah, if you cache at the very top layer, then you implicitly get caching on things like network shares or MTP (usb phone filesystem). problem then is, the underlying layers need to be able to reach up and invalidate cached data for particular files (say, when the file server tells you that it broke an opportunistic lock)
11:07:07 <doug16k> also, the underlying layer needs to indicate whether a give I/O is even eligible for caching, the network might have denied an opportunistic lock of a range of the file
11:07:52 <bcos> NFS is nasty (regardless of what you do).. :-)
11:07:58 --- quit: mattc_ (Quit: Leaving)
11:08:48 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
11:10:04 --- quit: zeus1 (Ping timeout: 256 seconds)
11:11:19 <bcos> (there's multiple reasons why versioning file systems are awesome, including "everything can always be cached" and including not needing any locks)
11:11:38 --- join: M1cha (~M1cha@2a02:908:5a3:da80:7a8d:2699:26c0:ba14) joined #osdev
11:13:37 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
11:21:35 <heat> bcos: Apparently, linux's block cache uses the vfs's pages as its buffers
11:21:41 <heat> not a bad idea, might do that
11:23:39 <bcos> In general; every memory mapped file uses shared pages (pages shared with VFS cache and the process/es)
11:24:01 <heat> ye, I do that
11:24:54 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
11:25:54 <bcos> It's a good way to avoid a lot of RAM consumption (until someone decides processes should use ASLR and shared libraries, and all those nice shared pages end up modified differently for each process).. :-)
11:26:57 <heat> bcos: Shared libraries don't work like that
11:27:14 <heat> you just patch the GOT and the PLT
11:27:22 <heat> there's no .text patching anymore
11:27:42 --- quit: trout (Ping timeout: 240 seconds)
11:28:15 <bcos> Depends on which scheme you use (Windows/PE is quite different)
11:28:50 <bcos> ..but you still modify some pages (even if it's just GOT and PLT)
11:29:17 <heat> that's inevitable
11:29:17 --- join: tacco| (~tacco@i59F4F99E.versanet.de) joined #osdev
11:29:24 <heat> ASLR > a few pages
11:31:08 --- quit: glauxosdever (Quit: leaving)
11:32:14 --- quit: isaacwoods (Quit: isaacwoods)
11:34:43 <doug16k> heat, you don't have to make it be at a different address in every process. the address of a shared object can be constant across all processes until the next boot
11:34:57 <doug16k> but even if you did, it'd just be the GOT/PLT being unique to each process
11:35:44 <heat> my OS randomizes everything(because of the mmap base being randomized)
11:36:06 <heat> works fine because only the got and plt are getting MAP_PRIVATE
11:36:16 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
11:37:40 <doug16k> the PLT is definitely overboard. who thought up the idea of defining malloc in your executable, and magically making every shared object call your malloc. insane
11:38:28 --- quit: angel0xff (Ping timeout: 244 seconds)
11:38:37 <doug16k> making it just like static linking? ok, I get that, but it's unnecessarily good
11:39:21 <heat> doug16k: That's why musl declares most libc functions as protected symbols
11:40:09 <heat> the libc can't break that way
11:44:41 <heat> and overriding malloc isn't officially supported
11:44:43 <doug16k> exactly. step 1 of making a shared object: turn it off
11:46:42 --- quit: pie___ (Ping timeout: 240 seconds)
11:54:16 --- quit: prokbird (Ping timeout: 256 seconds)
11:54:27 --- join: zeus1 (~zeus@154.226.106.180) joined #osdev
11:56:04 --- quit: gxt (Quit: WeeChat 2.1)
11:56:35 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
11:57:39 --- join: Matviy (49dff905@gateway/web/freenode/ip.73.223.249.5) joined #osdev
11:59:05 --- join: tanner00 (adefc55e@gateway/web/freenode/ip.173.239.197.94) joined #osdev
11:59:12 <heat> https://upload.wikimedia.org/wikipedia/commons/3/30/IO_stack_of_the_Linux_kernel.svg
11:59:16 <heat> so simple
11:59:59 --- quit: variable (Ping timeout: 276 seconds)
12:01:06 <tanner00> hi all
12:01:37 <heat> hi dad
12:01:42 --- quit: jjuran (Quit: jjuran)
12:04:12 --- nick: atk -> atk_t
12:06:10 --- nick: atk_t -> _Atk
12:06:52 <tanner00> odd
12:07:01 <heat> even
12:08:27 <Matviy> If a PCI device resource file (resource0) from sysfs is mmaped into a userspace process, what is actually being mapped?
12:08:49 <heat> Matviy: The mmio region
12:08:52 <Matviy> As I understand it, all sysfs files are attributes, so is there some mmap handler specified for the resource0 attribute that maps the device's physical address into userspace?
12:08:53 <heat> pretty sure
12:08:59 <heat> ye
12:09:04 <heat> I think so, at least
12:09:30 <Matviy> Got it
12:10:00 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
12:10:27 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
12:13:29 --- join: pie___ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
12:14:13 --- join: bm371613 (~bartek@2a02:a317:603f:9800:3d21:d4ea:8e13:962a) joined #osdev
12:18:33 --- quit: rawste (Quit: Sleep....)
12:28:35 --- quit: zaquest (Ping timeout: 244 seconds)
12:29:24 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
12:30:14 --- join: nicht (~nicht@2804:7f1:2080:5ccc:7ec3:880d:f3f9:f96) joined #osdev
12:30:28 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
12:31:01 --- quit: spare (Quit: leaving)
12:31:09 --- quit: SopaXorzTaker (Remote host closed the connection)
12:32:09 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
12:32:42 --- quit: trout (Ping timeout: 240 seconds)
12:35:46 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
12:37:01 <grange_c> On intel 32 bits, what is the stack-alignment required before calling a C function? 8 or 16 bytes (or an other value?)?
12:37:02 --- join: m_t (~m_t@p5DDA2FB6.dip0.t-ipconnect.de) joined #osdev
12:37:19 <heat> grange_c: Might be 16 bytes
12:37:31 <heat> at least for x64
12:38:02 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
12:38:12 <grange_c> I agree for x64, but i'm analysing a 32bits binary and i was pretty sure until then it was 4 bytes, but this one seems to align to 16bytes, so i'm confused.
12:38:18 --- join: glauxosdever (~alex@80.107.168.7) joined #osdev
12:38:34 <heat> yes, 4 bytes
12:38:46 <heat> but depends if sse is enabled I bet
12:39:03 <heat> gcc might align to 16 bytes if sse is enabled
12:39:35 <froggey> 16 bytes in the most recent 32-bit abi
12:40:24 <heat> it is?
12:40:50 <froggey> yeah
12:40:53 <grange_c> Oh
12:40:58 <grange_c> That would explain my confusion
12:41:54 <heat> froggey: Is it really in the sysv abi or just gcc?
12:42:15 <heat> (can't open the pdf, it's broken in my browser)
12:43:15 <doug16k> grange_c, you might as well make it 16 byte, from there in, the compiler will maintain it, and it won't hurt if it only requires 8 byte
12:43:35 <froggey> "The end of the input argument area shall be aligned on a 16 (32 or 64, if __m256 or __m512 is passed on stack) byte boundary."
12:43:38 <froggey> from https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf
12:43:44 <doug16k> but yeah, it's 16 byte even on 32 bit afaik
12:43:47 <froggey> I'm sure this used to be on 01.org, but I can't find it
12:43:58 <heat> thanks
12:44:02 <grange_c> Ok, thanks!
12:44:38 <froggey> the old old abi published by sco used a 4 byte alignment
12:46:55 <doug16k> sorry if this is obvious, but 16 byte is also inherently 8, 4, and 2 byte aligned at the same time
12:47:53 <tanner00> Yes
12:48:23 <graphitemaster> C requires that memory allocation via malloc/calloc and realloc be suitably aligned by the largest type, and the alignment of the largest type is actually required to be sizeof(max_align_t), C11 further extends that the alignment of VLAs (variable length arrays) also be the same, so the compiler tends to keep the stack aligned to that too (since VLAs are on the stack)
12:49:12 --- quit: manzerbredes (Ping timeout: 240 seconds)
12:49:32 <graphitemaster> so abis aside, it's safe to assume that stack will be aligned sizeof(max_align_t) regardless of ABI
12:50:12 <graphitemaster> that doesn't mean it will be exact, it can be larger, e.g 32 is also 16, 8, 4, 2, etc aligned at the same time
12:51:24 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
12:51:24 <graphitemaster> I guess I should iterate this is only true for C11 conforming compilers
12:51:32 <graphitemaster> which MSVC isn't ;-)
12:51:45 <graphitemaster> MSVC gets max_align_t wrong even for win64
12:52:07 <doug16k> the true max align for x86 is 64 byte alignment, because of xsave, but such an obscure case is not likely to be taken into consideration at every function entry
12:52:18 --- quit: zeus1 (Ping timeout: 240 seconds)
12:52:25 <graphitemaster> name a 64 byte data type in the arch :P
12:52:32 <doug16k> xsave area
12:52:33 <graphitemaster> inb4 CACHE LINE
12:52:47 <heat> the true max align for x86 is 4MB
12:52:54 <graphitemaster> ?
12:52:55 <doug16k> yes, of course it is cache line alignment
12:53:04 <doug16k> for now anyway :)
12:53:09 <heat> HUGE PAGES
12:53:10 <graphitemaster> page sizes on x86 are 4K :P
12:53:35 <heat> I LOVE ME SOME HUUUUUUUUUUUUUUUUUUUUGE PAGES
12:54:05 <Brnocrist> so 1gb
12:54:25 <heat> there are no 1gb pages in x86
12:54:33 <graphitemaster> sure there is
12:54:40 <graphitemaster> PSE-36 allows for 1TB pages too
12:54:48 <tanner00> ugh
12:55:21 <doug16k> graphitemaster, you sure about 1TB pages?
12:55:35 <heat> it's the future of pages
12:56:02 <heat> when kernels can't even use 2MB pages, you just add 1TB ones
12:56:08 <graphitemaster> I think I got the wrong extension, but it was in that new Intel paper that increased the addressable space of the architecutre (by non canoncilizing addresses to 48 bits with hardwared zero bits)
12:56:21 <Brnocrist> heat: it does
12:56:24 <graphitemaster> allowing for I think 56 bits?
12:56:32 <heat> graphitemaster: PML5?
12:56:33 <Brnocrist> but who should use 1tb page?
12:56:33 <graphitemaster> anyways they also added another layer of page table entries
12:56:40 <graphitemaster> and up to 1TB page sizes
12:56:50 <doug16k> before that they ought to allow 512GB pages
12:56:58 <doug16k> just set PSE bit in PML4
12:57:31 <doug16k> which is currently illegal
12:57:35 <graphitemaster> 512GB pages would be useful for webbrowsers, just ask for one page of memory to implement your heap and be done
12:57:46 <doug16k> amen
12:57:47 <heat> lol
12:58:10 <graphitemaster> I'm not even kidding, give every tab 512GB of virtual address space
12:58:18 <Brnocrist> graphitemaster: same page for multi threads?
12:58:20 <graphitemaster> fucking javascript
12:58:35 <tanner00> overkill
12:58:44 <graphitemaster> is it tho?
12:58:46 <doug16k> it would have to be 512GB aligned and sized in 512GB increments though
12:58:52 <grange_c> "give every tab 512GB of virtual address space" is that the consequence of Meltdown and KAISER? x)
12:58:59 <doug16k> so, unusable with < 1TB memory
12:59:02 <Brnocrist> I can't image a single tab with 512gb of memory, but js..
12:59:43 <grange_c> Wait until 2050
12:59:54 <graphitemaster> Brnocrist, well what if that one tab is running jslinux and emscripten compiled webbrowser itself, that'll need nested paging extensions which will be a feature, via webvirtualization, a javascript api for nested paging and virtualization :P
12:59:54 <grange_c> Where a 3D cube rotating will take 64gb RAM
13:00:09 <Brnocrist> so reduce mmu just to check memory perms and kill all vm/tlb stuff when virt mem == phys
13:00:25 <grange_c> But eh, the same cube will be run through an cloud-OS fully written in cryptocloudjs, the new js framework that kick asses in 2050
13:00:45 <heat> when will the cpu start running node.js
13:00:51 <Brnocrist> graphitemaster: so just a wasm version of emacs? :D
13:01:10 <grange_c> Isn't ARM that added some instructions to quickly decode JS floats?
13:01:18 <grange_c> (Or am i the victim of bad press?)
13:01:21 <graphitemaster> you need at least 512GB anyways to store the entire blockchain of all the cryptocurrencies known, which will be a requirement to do transactions on the web in the future because amazon and all the internet companies will have their own alt coin
13:01:24 <doug16k> js uses double
13:02:07 <doug16k> when JIT can't infer that an int will do anyway
13:02:08 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
13:02:16 <heat> https://www.youtube.com/watch?v=um-1fAVU1OQ
13:02:16 <bslsk05> ​'WE GOT INTEL'S PROTOTYPE GRAPHICS CARD!!' by Linus Tech Tips (00:14:45)
13:02:19 <heat> this is interesting
13:02:24 <heat> ofc he didn't get it running
13:02:35 <graphitemaster> I first have to convert my bitcoin into etherum so I can use this one eschange to give me amazon prime coin to buy fleshlights, condom and lube from amazon
13:02:47 <graphitemaster> the FUTURE!
13:02:48 <heat> it's linus tech tips, were you expecting competence or something?
13:02:59 <Brnocrist> no please, cryptomoney here too?
13:03:44 <graphitemaster> I wonder what x86 will look like in another 50 years.
13:03:57 <heat> cryptomula everywhere
13:04:07 <doug16k> hear about that guy that got into bitcoin early, gave up mining it because it was worthless then, later found the drive containing over $1 million worth of bitcoin, and threw it in the garbage?
13:04:07 <graphitemaster> seeing as there's no end in sight for it
13:04:09 <grange_c> My my, i tried to watch the video but the add for Corsair is way too heavy
13:04:19 <Brnocrist> graphitemaster: they will die before
13:04:31 <graphitemaster> x86 is too big to fail
13:04:37 --- quit: variable (Ping timeout: 265 seconds)
13:04:47 <Brnocrist> is too big to not fail
13:04:48 <graphitemaster> it's like Google, it's not going anywhere anytime soon.
13:04:55 <heat> 512-bit GDT
13:05:13 <grange_c> What about Microsoft? Too big to fail too?
13:05:16 <heat> segmentation makes a comeback
13:05:19 <heat> grange_c, definitely
13:05:28 <graphitemaster> IBM is still kicking dude
13:05:42 <Brnocrist> google and ms are not producing bad arch
13:05:56 <Brnocrist> graphitemaster: power9 is nice
13:06:27 <grange_c> 128-bits integers
13:06:43 <grange_c> Which will be the default int size
13:06:49 <doug16k> that's awful
13:06:51 <heat> 512
13:06:53 <graphitemaster> unlike GPUs, we made the mistake of distributing and running native code. When from the beginning we should've been running a portable byte code or intermediate representation the OS AOT compiled.
13:07:04 <graphitemaster> That would make CPUs much easier to fix
13:07:37 <grange_c> 16bits makes a come back. "It's vintage", they say
13:07:38 <Brnocrist> https://www.top500.org/news/china-begins-domestic-production-of-amd-server-cpus/
13:07:39 <bslsk05> ​www.top500.org: China Begins Domestic Production of AMD Server CPUs | TOP500 Supercomputer Sites
13:07:52 <heat> I prefer 24 fps for the cinematic feel
13:08:36 <Brnocrist> graphitemaster: GPU are modern :P
13:09:11 --- quit: Matviy (Quit: Page closed)
13:09:17 <doug16k> let me know when gpus have 1536 out of order cores and 1536 independent L1 caches :P
13:09:59 <Brnocrist> you don't need it with GPU I guess
13:10:06 <tanner00> graphitemaster: 2038 problem?
13:10:25 <heat> tanner00, no
13:10:31 <doug16k> ...oh and all cores have independent instruction pointers. kthx
13:10:33 <heat> it's not the cpu that needs fixing
13:10:39 --- quit: nicht (Ping timeout: 256 seconds)
13:10:43 <tanner00> ok but seriously
13:10:47 <tanner00> i get that
13:10:55 <tanner00> but you think x86 will be around in 50 years??
13:11:07 <heat> maybe
13:11:22 <Brnocrist> doug16k: there are shader core
13:11:36 <heat> do you even know how computing will be like?
13:11:55 <tanner00> No, but I certaintly hope people will leave x86 by then
13:12:14 <heat> meh
13:12:49 <tanner00> A more interesting question for me might be how long Microsoft lasts?
13:12:54 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
13:12:58 <doug16k> tanner00, as long as they continue to become more and more outrageously powerful, yes
13:12:59 <heat> forever
13:13:30 <tanner00> Well, they certaintly can't last forever, because humans won't last forever
13:13:39 <heat> I don't see microsoft or google going away
13:14:10 <heat> apple can die off because eventually people might stop buying their things
13:14:29 <doug16k> microsoft is doing their best to nosedive the company, but the wings have so much lift then can't get into a descent
13:14:36 <heat> facebook will die when whatsapp/instagram/facebook dies
13:14:41 <heat> doug16k, why?
13:14:48 --- quit: drakonis (Ping timeout: 240 seconds)
13:14:52 <tanner00> I understand Google, but not Microsoft.
13:15:04 <doug16k> heat, they are trying to become an ad company
13:15:24 <doug16k> having near total monopoly on operating systems isn't good enough
13:15:41 <heat> they dont sell operating systems anymore
13:15:52 --- quit: macdonag2 (Ping timeout: 256 seconds)
13:16:14 <heat> only for people that somehow don't have windows 10 yet
13:16:38 <doug16k> right. why would they throw away their cash cow?
13:17:16 <glauxosdever> Less than a month ago, youtube blocked videos from MIT and the Blender Foundation. In 2014, they blocked Sintel (a movie by the Blender Foundation again). I read in various threads/comments that they remove videos for no apparent reason.
13:17:56 <glauxosdever> And it's interesting how most people still upload videos to youtube
13:18:11 <heat> "There was speculation that YouTube's content-filtering system is to blame but YouTube says the problem is administrative in nature."
13:18:18 <glauxosdever> (I do use youtube, not because I like it, but because most videos that interest me are at youtube)
13:18:46 <glauxosdever> Whatever they say, they are to blame
13:18:47 <heat> it's interesting how you're trying to pretend it was on purpose
13:18:49 <doug16k> why do people contribute content to facebook for absolutely nothing? at least their is a chance of getting monetization from google
13:18:55 <doug16k> there*
13:18:58 <heat> are they really?
13:19:14 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
13:19:15 <glauxosdever> The 2014-Sintel incident was done after SONY made a false copyright claim
13:19:30 <heat> doug16k: They get paid to do so
13:19:39 <glauxosdever> I'm not trying to pretend anything actually
13:19:56 <doug16k> heat, facebook gives you money for posting popular content?
13:20:04 <heat> the facebook group pays content creators to put out videos in their platforms
13:20:15 <heat> (instagram, facebook)
13:20:27 <heat> that's why people started posting things in IGTV since day 1
13:20:28 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
13:21:02 <heat> glauxosdever: Then don't say they blocked it, it just got blocked by their automated system
13:21:22 <heat> If you believe it's flawed, apply for a job at youtube
13:21:42 <glauxosdever> No thanks. I'd rather see a competitor
13:21:59 <heat> that's not going to happen
13:22:47 <tanner00> I don't see that happening soon
13:23:13 <glauxosdever> I don't see that either actually
13:23:45 <tanner00> hate the new reddit
13:24:01 <heat> you can switch back
13:24:11 <heat> fear not
13:24:18 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:24:30 <tanner00> My fear is that one day they'll remove old.reddit.com
13:24:47 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:24:54 <heat> you don't need old.
13:24:57 <heat> there's a setting
13:25:07 <heat> and it probably won't happen
13:25:21 --- join: drakonis__ (~drakonis@unaffiliated/drakonis) joined #osdev
13:26:12 --- quit: drakonis_ (Ping timeout: 240 seconds)
13:26:14 --- quit: drakonis (Client Quit)
13:26:16 --- nick: drakonis__ -> Drakonis
13:26:19 --- nick: Drakonis -> drakonis
13:26:46 <tanner00> This doesn't exactly apply but I fear an extend, embrace, extenguish scenario
13:27:18 --- quit: blackandblue (Quit: Leaving)
13:28:25 <tanner00> Has anyone had trouble with the extended read bios function?
13:28:33 --- quit: Drakonis[m] (Changing host)
13:28:34 --- join: Drakonis[m] (drakonisma@unaffiliated/drakonis) joined #osdev
13:28:34 --- quit: Drakonis[m] (Changing host)
13:28:34 --- join: Drakonis[m] (drakonisma@gateway/shell/matrix.org/x-kecyqqukcpfbjhpd) joined #osdev
13:28:41 <tanner00> Carry being set for sectors > 1?
13:30:52 <heat> what's that=
13:30:53 <heat> ?
13:31:08 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
13:31:51 --- quit: [Brain] (Read error: Connection reset by peer)
13:32:13 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
13:33:59 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:34:51 <tanner00> It's an int 0x13 real mode function
13:35:28 <glauxosdever> AH=0x42?
13:35:41 <heat> is it one of the 48-bit lba ones?
13:35:42 --- quit: trout (Ping timeout: 240 seconds)
13:37:14 <bcos> heat: Yes - this one: http://www.ctyme.com/intr/rb-0708.htm
13:37:15 <bslsk05> ​www.ctyme.com: Int 13/AH=42h
13:39:01 <glauxosdever> Are you sure you are reading just one sector?
13:39:10 <glauxosdever> Er
13:39:23 <glauxosdever> Are you sure you are reading less than 127 sectors?
13:40:15 <tanner00> yes
13:40:28 <bcos> Brute force search time!
13:40:29 <tanner00> It sets carry if sectors is > 1
13:40:35 <tanner00> (QEMU)
13:40:52 <glauxosdever> How many do you actually try?
13:40:53 <heat> tanner00: You sure it's supported?
13:41:04 <glauxosdever> QEMU does support it
13:41:11 <bcos> ..for(startingLBA = 0 to 100) { for(sectorCount = 1 to 100) { read(startingLBA, sectorCount); }
13:41:12 <glauxosdever> Unless it's a floppy I think
13:43:15 <glauxosdever> Before using INT 0x13 extensions, you need to check if they are supported
13:43:48 <glauxosdever> (Although they should be supported on any reasonably new, mid and old machine)
13:44:02 <bcos> It's supported by Qemu for 1 sector at least
13:45:02 <bcos> (but yes, ideally/eventually you'd have a fall back to the old CHS BIOS function)
13:45:05 --- quit: user10032 (Quit: Leaving)
13:47:53 --- quit: baschdel (Ping timeout: 255 seconds)
13:48:18 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
13:49:59 --- quit: rawste (Quit: Sleep....)
13:50:38 --- nick: _Atk -> atk
13:53:12 --- quit: zeus1 (Ping timeout: 240 seconds)
13:59:12 --- quit: andrei-n (Ping timeout: 240 seconds)
14:04:27 --- quit: macdonag2 (Quit: macdonag2)
14:04:47 --- quit: bm371613 (Quit: Konversation terminated!)
14:05:07 <doug16k> tanner00, it can fail if you cross a 64KB boundary too
14:05:12 --- quit: M1cha (Ping timeout: 240 seconds)
14:05:39 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
14:05:51 <doug16k> it can also partially succeed and report failure. check the sector count field, it will update it with the number of sectors transferred
14:05:53 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:08:01 --- join: korans (~korans@93.191.203.83) joined #osdev
14:08:25 --- quit: variable (Ping timeout: 265 seconds)
14:08:33 <doug16k> in my bootloader at the first failure that has at least one sector transferred, I fall back to avoiding crossing 64KB boundaries, and limit the sector count to 32KB per call. then it naturally realigns itself to avoid the 64KB boundary issue and the 127 maximum sectors issue
14:12:15 <doug16k> tanner00, like this -> https://github.com/doug65536/dgos/blob/master/boot/diskio.cc#L174
14:12:16 <bslsk05> ​github.com: dgos/diskio.cc at master · doug65536/dgos · GitHub
14:13:23 <doug16k> line 187 shouldn't say unlikely. I now know it's actually likely for that to be needed
14:16:07 <doug16k> the code in that file also implements 64 bit physical address extension, and either having EDD version 3 isn't an adequate check, or seabios has a broken implementation. in any case I bounce buffer it if it is > 1MB unconditionally now
14:16:44 <doug16k> if the buffer address is > 1MB*
14:17:42 <doug16k> if I find out how to reliably detect 64 bit support, I'll remove the 0 && on line 163
14:19:09 <bcos> Can't load a sector at 0x0000000123456789 and see if it appears at 0x23456789?
14:20:10 --- quit: Naergon (Ping timeout: 260 seconds)
14:20:47 --- quit: MrOnlineCoder (Quit: Goodbye)
14:21:01 <doug16k> here's the issue though: if you try to use that extension, you put 0xFFFF:0xFFFF for the segment and offset, so it reads to the BIOS area. sure, I could allocate a buffer and see if it copies it to the right place I suppose, but it will wraparound and potentially write 512-16 bytes to 0000:0000
14:21:40 <doug16k> I suppose I could back that up, but it might interfere with the int 13h call itself
14:22:41 <doug16k> s/will wraparound/could wraparound/
14:23:10 <bcos> Ah - maybe do a write instead (then read back the sector you wrote and see what it matches)
14:23:42 <bcos> Probably a lot easier to just use bounce buffer unconditionally...
14:24:04 <doug16k> writing is a clever idea if I cached whether it worked :)
14:24:20 --- quit: heat (Ping timeout: 255 seconds)
14:24:39 <doug16k> but then it might fail to boot when moved to another machine, so then I'd have to cache a hash of the bios or something :)
14:25:19 <tanner00> After int 0x13 the sectors field of the DAP gets set to 1
14:25:28 <doug16k> that code is ultra fast. the progress bar for my kernerl load is a blip
14:25:55 <doug16k> tanner00, then it transferred 1 sector. your code must tolerate that, that's the contract for ah=42h,int 13h
14:26:13 <doug16k> it was a partial success
14:28:24 <doug16k> a bios is allowed to say "screw it" and return with less than all of the sectors transferred, if it crosses a 64KB boundary, or crosses a cylinder boundary, or if it feels like it
14:29:37 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
14:31:34 <bcos> doug16k: And return "ah = 0x01 = invalid function in AH or invalid parameter" for a partial success?
14:32:38 <doug16k> I saw it returning invalid parameter, but yeah there is another code for crossing a 64KB boundary. I don't trust the bios to return accurate information in there though, I just see if carry was set and go straight to reading the sector count
14:33:06 <doug16k> I suppose that could backfire for particularly bad bioses. I'll cross that bridge if I come to it
14:33:12 * bcos needs a time machine and a spiked baseball bat
14:33:17 <doug16k> yes
14:33:21 <bcos> :-)
14:33:36 --- join: jjuran (~jjuran@172.58.185.252) joined #osdev
14:33:43 <heat> Thank mr. EFI
14:34:05 <heat> (which has it's own set of hugely disturbing problems)
14:35:37 <heat> (including mindblowingly stupid bugs such as touching boot services data after ExitBootServices)
14:35:56 <heat> (and Tianocore being larger than the linux's core kernel)
14:36:32 <clever> ive also heard of bugs in some vendor EFI implementations, like being unable to delete a record from the efivars, if the partition behind that uuid doesnt exist
14:36:46 <clever> so if you delete the efisys partition first, you cant ever remove it from the efivars as a boot entry
14:36:49 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:37:29 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
14:38:21 <heat> https://www.youtube.com/watch?v=V2aq5M3Q76U
14:38:21 <bslsk05> ​'EFI and Linux: the future is here, and it's awful - Matthew Garrett' by Linux.conf.au 2012 -- Ballarat, Australia (00:53:10)
14:38:22 <doug16k> my only real gripe with Tianocore so far is that it tells you absolutely nothing useful about failure to load the EFI application. just silently drops to another prompt in the shell
14:38:24 <heat> this is the best talk ever
14:39:23 <heat> this guy gives the best talks
14:39:32 <doug16k> oh and the performance for drawing on the screen is atrocious. I don't know why they need to calculate PI to 50,000 digits between each character update in the EFI setup screen
14:39:42 --- quit: trout (Ping timeout: 240 seconds)
14:39:47 <heat> also I'm pretty sure he lurks around here sometimes as mjg*
14:44:24 <tanner00> What is Tianocore?
14:44:29 <tanner00> I know it has to do with UEFI
14:44:46 <klys> it's part of ovmf, which emulates uefi in qemu
14:45:05 <heat> no
14:45:13 <heat> Tianocore is *the* uefi implementation
14:45:21 <heat> that most firmware vendors use
14:45:31 <heat> written by intel
14:45:47 <_mjg> heat: he doe snot
14:45:53 <_mjg> heat: that's a different person
14:46:06 <heat> oh right
14:46:08 <heat> sorry then
14:46:18 <_mjg> well he may be lurking under a very differnet nickname
14:46:20 <_mjg> :)
14:46:22 <heat> didn't see your name
14:47:13 --- quit: ptx (Read error: Connection reset by peer)
14:48:23 --- join: ptx (~ptx@563400ad.rev.stofanet.dk) joined #osdev
14:48:37 <drakonis> that's a video from 6 years ago
14:48:58 <heat> it never stops being true
14:49:17 <drakonis> he goes by mjg59 anyways
14:49:51 <heat> that's why I thought it was him
14:50:03 <drakonis> he's not here though
14:50:29 <heat> ye
14:51:00 <drakonis> ah well
14:51:01 <drakonis> gotta go
14:51:30 --- quit: drakonis (Remote host closed the connection)
14:52:50 --- quit: zeus1 (Ping timeout: 260 seconds)
14:52:54 <tanner00> doug16k: This is weird, but I think QEMU will read the blocks only if they contain non-zero data?
14:53:14 <tanner00> I filled the end of the binary with 0xff3 and QEMU reads exactly what I tell it to
14:55:50 --- quit: pie___ (Ping timeout: 244 seconds)
14:56:53 <doug16k> tanner00, no way
14:57:20 <doug16k> unless it gained clairvoyance and can tell what is in a sector before it reads it
14:57:23 <tanner00> No way as in "weird" or no way as in "doesn't happen"?
14:58:04 <heat> doesn't happen
14:58:09 <tanner00> Oh, I think you're right
14:58:16 <tanner00> Ok, I was just being dumb.
14:58:58 <doug16k> tanner00, you can look at the source for the bios in qemu. it's called seabios
14:59:27 <doug16k> that one is probably named something like disk_1342 IIRC
14:59:32 <tanner00> Oh, cool
14:59:48 --- quit: Love4Boobies (Quit: Leaving)
15:01:05 <doug16k> or is it handle_1342... something like that
15:02:39 <tanner00> Ok, I have another question
15:03:48 <tanner00> If your file isn't request is too big for the bin file in question, it will stop there and report how much it read to that point?
15:03:58 <tanner00> no isn't*
15:04:27 <doug16k> yes. it will attempt to do what you said but might stop early and update the sector count field with how many it actually read
15:05:00 <doug16k> so if you try to read 32 sectors, and the sector count field says 12 after the call, it read 12 sectors
15:05:15 <doug16k> carry will be set in that case
15:05:28 <tanner00> Ok, then all is well and I know why it set ah=1
15:05:31 <tanner00> Thank you :)
15:05:44 --- quit: glauxosdever (Quit: leaving)
15:05:54 <doug16k> if it read all 32 then carry will be clear, and the bios *should* leave the sector count at 32
15:06:14 <tanner00> 127* ?
15:06:16 <doug16k> almost certainly will say 32
15:06:25 <doug16k> no in my example I'm reading 32 sectors
15:06:30 <doug16k> that's why 32
15:06:49 <tanner00> Ok, but the maximum portable limit is 127, yes?
15:07:04 <doug16k> yes, but you should also avoid crossing 64KB boundaries
15:07:24 <doug16k> if you handle partial success properly, yes, the maximum portable sector count is 127
15:08:08 <doug16k> some bad bios programmers (at phoenix) thought 128*512 won't fit in a 16 bit register, so they crippled the API :)
15:08:24 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
15:09:01 <doug16k> they didn't know about this cool thing called dx, or the carry flag
15:09:38 <tanner00> You mean (64kib - 0x7e00) / 512 would be the maximum sectors for a full read?
15:09:42 --- quit: angel0xff (Ping timeout: 264 seconds)
15:09:59 <tanner00> Assuming you start reading at 0x7e00
15:10:01 <doug16k> might be. you have to tolerate that
15:10:31 <doug16k> the primary reason for the 64KB boundary issue is floppy DMA. ISA DMA can't cross a 64KB boundary
15:10:43 <doug16k> but you never know if a BIOS will enforce that on all calls
15:10:52 <clever> heat: heh, 27mins into the video you linked, he mentions the thing i said about undeleteable variables
15:11:05 <doug16k> just tolerate partial success and stay <= 127 and you're good
15:11:43 <heat> doug16k: ATA PCI DMA can't cross it either
15:11:44 --- quit: variable (Ping timeout: 276 seconds)
15:11:56 <doug16k> heat, right. good point
15:12:36 <bcos> A good BIOS would break a larger read up into smaller pieces that don't cross boundaries
15:12:55 <bcos> (if necessary)
15:14:57 --- quit: Kimundi_ (Ping timeout: 244 seconds)
15:16:24 <tanner00> I thought extended reads were more modern and simpler lol
15:17:10 <heat> if you want modern and simple you mustn't use the bios
15:17:10 <doug16k> tanner00, they allow very high LBAs. that's the benefit
15:18:05 <doug16k> and they could allow you to directly read to the entire 64 bit physical address space, if you figure out how to detect it ;)
15:19:17 <doug16k> I tried. just being EDD version 3 isn't enough of a check :(
15:20:02 <heat> EDD?
15:20:21 --- quit: sortie (Quit: Leaving)
15:20:32 <doug16k> heat, there are 3 versions of the int 13h extensions
15:21:28 <doug16k> phoenix proposed them and they were widely adopted
15:21:44 <doug16k> http://mbldr.sourceforge.net/specsedd30.pdf
15:22:06 <doug16k> ^ that's where ah=42h came from
15:24:54 --- join: pie___ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
15:25:00 <doug16k> they definitely get my vote for proposing a 64 bit LBA field way back in 1998. at least one person in the industry has foresight
15:30:12 <doug16k> then, for the triple front flip trampoline finale slam dunk, they proposed a 64 bit address field
15:30:22 --- quit: palk ()
15:31:20 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
15:34:42 --- quit: w41 (Ping timeout: 256 seconds)
15:36:02 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
15:37:53 --- quit: Asu (Quit: Konversation terminated!)
15:40:27 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
15:40:42 --- quit: [Brain] (Ping timeout: 240 seconds)
15:41:22 <tanner00> Could you write your entire OS without exiting boot services?
15:41:30 <tanner00> What is the benefit of exiting boot services?
15:41:46 <bcos> No
15:42:28 <CompanionCube> tanner00: you're no longer constrained by UEFI's flaws and limitations.
15:42:47 <bcos> Think of it in terms of hardware ownership. Before you exit boot services firmware owns all the hardware and you can't/shouldn't touch it, and after you exit boot services you own the hardware and firmware can't/shouldn't touch it.
15:43:12 <bcos> ..if you never exit boot services then you don't control any of the hardware and can't call it an OS.
15:43:12 --- quit: trout (Ping timeout: 240 seconds)
15:43:23 <bcos> (it's a UEFI application)
15:43:26 <tanner00> Oh, ok.
15:45:25 <heat> + you can't possibly touch the address space
15:46:14 <heat> (I mean, you can, but it's just not a very good idea)
15:47:55 --- join: booyah (~bb@193.25.1.157) joined #osdev
15:51:19 --- quit: jjuran (Quit: jjuran)
15:52:57 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
15:57:43 --- quit: immibis (Ping timeout: 264 seconds)
16:00:55 --- quit: Tazmain (Quit: Leaving)
16:03:38 --- join: nicht (~nicht@2804:7f1:2080:5ccc:9a91:91c7:ad26:d430) joined #osdev
16:03:39 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
16:05:27 <chrisf> bcos: a lot of 'shouldnt' on both sides there in reality :)
16:06:40 --- quit: heat (Quit: Leaving)
16:10:18 --- join: bemeurer (~bemeurer@199.83.221.197) joined #osdev
16:11:33 <doug16k> tanner00, you can only call EFI on the boot CPU. that cripples an OS. all calls are serialized one by one. Plus, the performance of EFI calls is likely to have much worse performance than a real kernel's drivers
16:11:48 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
16:12:38 <doug16k> if you want your whole OS to freeze during every I/O, go for it :)
16:13:49 <tanner00> Damn, didn't know about that lol
16:14:29 <doug16k> well, the other cpus can keep going doing non-I/O, but it would be terrible in general to serialize all calls and have nothing but synchronous I/O
16:14:37 <bcos> UEFI did add some asynch IO stuff..
16:14:47 --- quit: variable (Ping timeout: 276 seconds)
16:14:53 <doug16k> did they? I didn't notice any
16:15:43 <doug16k> likely serialized callbacks only on the bootstrap processor though
16:16:18 --- quit: Shamar (Quit: Lost terminal)
16:16:49 <pikhq> Of course, basically all of EFI's interfaces are still designed to only be *just* suitable for starting a "real" OS, anyways.
16:17:44 <doug16k> it would be interesting to have a desperate fallback to continuing to use EFI though, as a last resort for using a machine which happens to have an EFI driver your OS doesn't have
16:18:42 <doug16k> ...that you must have, like a NIC driver
16:20:39 <doug16k> you'd have to thoroughly abstract all hardware, so nothing depends on doing any direct hardware accesses
16:22:45 --- join: while1 (~while@69.61.171.22) joined #osdev
16:22:55 --- quit: tadni- (Read error: Connection reset by peer)
16:22:55 --- quit: while (Read error: Connection reset by peer)
16:22:55 --- quit: Affliction (Read error: Connection reset by peer)
16:23:41 --- join: Affliction (affliction@2402:1f00:8101:135::) joined #osdev
16:23:57 <doug16k> which means it would be all or nothing, since you can't safely touch hardware until you exit boot services
16:24:13 <pikhq> Well, there is the PCI IO protocol.
16:24:16 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
16:24:19 --- quit: zentrum (Ping timeout: 240 seconds)
16:24:22 <pikhq> I guess in principle you could do drivers via that?
16:24:25 <pikhq> I'd hate to though.
16:24:25 --- join: zentrum (soul@shell.franken.de) joined #osdev
16:24:26 --- quit: graphene (Ping timeout: 260 seconds)
16:24:26 --- quit: Olgierd (Ping timeout: 260 seconds)
16:24:49 --- quit: NightBlade (Ping timeout: 240 seconds)
16:25:08 <pikhq> (and wanna bet that's buggy everywhere?)
16:25:12 --- join: Olgierd (~Olgierd@ns364739.ip-91-121-210.eu) joined #osdev
16:25:18 --- quit: Olgierd (Changing host)
16:25:18 --- join: Olgierd (~Olgierd@unaffiliated/olgierd) joined #osdev
16:27:19 --- quit: kasumi-owari (Ping timeout: 240 seconds)
16:27:56 --- quit: bslsk05 (Ping timeout: 260 seconds)
16:28:41 <bcos> doug16k: I finally found it! What I was thinking of is "EFI_BLOCK_IO2_PROTOCOL.ReadBlocksEx()", which seems to have been introduced in UEFI version 2.3.1
16:29:16 <bcos> (spent ages trying to find it in older versions of the spec and was starting to question my sanity..)
16:29:32 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
16:29:52 --- join: bslsk05 (~bslsk@puckipedia.com) joined #osdev
16:31:11 <doug16k> bcos, yep, that's async. nice
16:31:21 <doug16k> have you found one word about SMP in the spec? I can't
16:31:47 <doug16k> I see them drawing diagrams of hypothetical busses with multiple CPUs, not a word about starting an AP or running SMP
16:32:57 --- quit: xenos1984 (Quit: Leaving.)
16:35:03 <bcos> doug16k: Once upon a time I saw a "draft proposal" to add SMP to UEFI (mostly a "call this function with all CPUs" interface). Haven't seen a mention since
16:35:54 <doug16k> pikhq, yeah, it's not quite as grim as I described. you could theoretically implement EFI drivers yourself
16:36:27 <doug16k> bcos, it's sorely needed. are people seriously going to use their 16 processor CPU on a uniprocessor OS?
16:37:11 <doug16k> intel was intimately involved right? you'd think they'd be jumping up and down like a gorilla if it doesn't have any SMP
16:37:59 <bcos> Uniprocessor OS?
16:38:23 <doug16k> how are you going to send an init/startup IPI in EFI?
16:38:43 <doug16k> sneak in and poke at the APIC I guess?
16:38:59 <pikhq> Intel shipped a 32-bit CPU with protected mode that was mostly used for 16-bit real mode programs; I don't think hardware and software talk much at Intel.
16:39:07 <bcos> Same as always - the INIT-SIPI-SIPI sequence
16:39:33 <doug16k> bcos, right, so now you can start poking directly at hardware without exiting boot services?
16:39:37 <bcos> (I don't know about other platforms - I'd assume they have a documented method somewhere)
16:40:20 <bcos> Erm. You can poke at hardware without exiting boot services without starting a CPU (but you shouldn't and the results may be undefined)
16:41:37 --- quit: antkit (Quit: Connection closed for inactivity)
16:42:02 <doug16k> and what would the trampoline do? run off and run code that has nothing to do with EFI I guess. hopefully you can allocate 4KB aligned memory for the trampoline in 0-9ffff range
16:42:24 <doug16k> and how would you IPI? start poking at the IDT?
16:42:45 <doug16k> slippery slope
16:44:19 <doug16k> I suppose you could monitor/mwait and do some mailbox thing to do communication with the bootstrap processor
16:44:32 <doug16k> hopefully the CPU has monitor/mwait :)
16:44:33 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
16:45:57 <CompanionCube> imo the closest to a purely uefi-using OS would be one that runs all your userspace in a bytecode interpreter/jit if that.
16:46:46 --- quit: sysfault (Read error: Connection reset by peer)
16:47:16 --- join: sysfault (~exalted@pool-108-53-210-20.nwrknj.fios.verizon.net) joined #osdev
16:47:42 --- quit: trout (Ping timeout: 240 seconds)
16:51:57 <clever> CompanionCube: that reminds me, i know somebody that is using llvm bytecode for all of his apps, and finalizing the compile at bootup
16:52:06 <doug16k> I think they forgot to invite a couple of people to the EFI design meetings
16:52:16 <clever> CompanionCube: what if you wrote the llvm bytecode->native translator in uefi bytecode? lol
16:52:57 <CompanionCube> clever: the first thing makes some amount of sense
16:53:08 <CompanionCube> one of IBM's systems goes halfway with it
16:53:31 <CompanionCube> all programs on it are compiled to an intermediate language, on first use the OS AOT compiles it to the CPU's native machine code.
16:54:09 <clever> CompanionCube: oh yeah, and older android systems have an install-time linker, to speed up the running of dalvik code
16:54:18 <clever> and newer android will just translate that dalvik to native at install time
16:54:30 <doug16k> there's no free software that compiles EFI bytecode, is there? I didn't look very hard but all I've found is a for-pay intel compiler
16:55:37 <CompanionCube> (for IBM, this feature came in handy when they once switched that OS's CPU to a different arch. Allowed them to maintain backwards compat by having the OS re-translate the program to the new ISA.)
16:58:17 --- quit: zeus1 (Ping timeout: 244 seconds)
17:06:07 --- quit: pie___ (Ping timeout: 264 seconds)
17:09:42 --- quit: tadni_ (Ping timeout: 240 seconds)
17:17:11 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
17:19:49 --- quit: variable (Ping timeout: 265 seconds)
17:29:23 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:29:25 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:29:48 --- quit: pie__ (Client Quit)
17:31:52 --- join: jack_rabbit (~jack_rabb@c-73-211-181-224.hsd1.il.comcast.net) joined #osdev
17:38:48 --- quit: X-Scale (Ping timeout: 256 seconds)
17:40:51 --- join: ybyourmom (~ybintell@vampire.ertos.nicta.com.au) joined #osdev
17:40:59 --- join: X-Scale (~ARM@83.223.242.197) joined #osdev
17:42:30 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
17:47:59 <doug16k> wow, I realized that there was a case where even a single sector read could cross a 64KB boundary. I forced my read code to bounce buffer that read and align the bounce buffer on a (1 << log2_sector_size) boundary to guarantee that at least one sector can be read
17:49:01 <doug16k> smh
17:49:49 --- quit: Guest56583 (Remote host closed the connection)
17:51:02 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
17:52:09 --- quit: freakazoid0223 (Remote host closed the connection)
17:52:34 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
17:53:12 --- quit: trout (Ping timeout: 240 seconds)
17:58:48 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
17:59:08 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
18:00:23 --- quit: tadni (Remote host closed the connection)
18:01:11 --- join: giraffe (skarn@gateway/shell/firrre/x-vlyvyibdjcknwcaz) joined #osdev
18:01:22 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
18:01:37 --- nick: giraffe -> Guest76646
18:02:48 --- quit: zeus1 (Ping timeout: 240 seconds)
18:06:57 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
18:07:14 --- join: NaNkeen (~nankeen@61.6.61.42) joined #osdev
18:07:44 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
18:11:45 --- quit: tanner00 (Ping timeout: 252 seconds)
18:11:46 --- quit: angel0xff (Ping timeout: 260 seconds)
18:12:50 --- quit: m_t (Quit: Leaving)
18:14:20 --- join: sixand (~Thunderbi@222.84.223.232) joined #osdev
18:20:56 --- quit: quc (Remote host closed the connection)
18:22:02 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
18:25:26 --- quit: variable (Ping timeout: 276 seconds)
18:32:18 --- quit: NaNkeen (Ping timeout: 240 seconds)
18:36:38 --- quit: promach_ (Quit: WeeChat 2.1)
18:47:25 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
18:48:51 --- join: tanner00 (2d389a22@gateway/web/freenode/ip.45.56.154.34) joined #osdev
18:52:37 --- quit: catern (Excess Flood)
18:53:10 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:54:19 --- join: catern (~catern@catern.com) joined #osdev
18:54:43 --- join: voiceftp (~voiceftp@host-85-118-226-104.academ.org) joined #osdev
18:56:29 --- quit: trout (Ping timeout: 265 seconds)
18:57:24 --- quit: tanner00 (Ping timeout: 252 seconds)
19:00:13 --- quit: stephen77 (Ping timeout: 244 seconds)
19:01:46 --- quit: zeus1 (Ping timeout: 244 seconds)
19:02:36 --- join: NaNkeen (~nankeen@61.6.61.42) joined #osdev
19:07:41 --- quit: nicht (Ping timeout: 276 seconds)
19:08:55 --- quit: NaNkeen (Ping timeout: 260 seconds)
19:11:12 --- quit: flacks (Quit: Leaving)
19:13:41 --- join: voice_ftp (~voiceftp@host-85-118-226-104.academ.org) joined #osdev
19:13:55 --- join: Plazma_ (~Plazma@freenode/staff-emeritus/plazma) joined #osdev
19:15:03 --- join: port8443 (~wizardmin@mtndewcode.red) joined #osdev
19:15:09 --- join: sixand1 (~Thunderbi@222.84.223.232) joined #osdev
19:15:09 --- join: tux3_ (tux@cmdline.org) joined #osdev
19:15:11 --- join: ZeDestructor_ (~ZD@unaffiliated/zedestructor) joined #osdev
19:15:21 --- join: dustinm`_ (~dustinm@68.ip-149-56-14.net) joined #osdev
19:17:00 --- join: _mjg_ (mjg@fook.org) joined #osdev
19:17:13 --- join: zeroSign1l (~ovi@62.178.73.241) joined #osdev
19:17:15 --- join: transist1r (~trans@S01060018f8f95df7.vc.shawcable.net) joined #osdev
19:17:18 --- join: cruxeter (~cruxetern@secspeed.com) joined #osdev
19:17:21 --- join: pisculic1i (pisculichi@shell.bshellz.net) joined #osdev
19:17:53 --- join: Kydd_ (kydd@dikunix.dk) joined #osdev
19:18:12 --- quit: X-Scale (Ping timeout: 240 seconds)
19:19:23 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
19:19:24 --- join: nwm- (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
19:19:28 --- join: zopsi_ (~zopsi@2607:5300:60:9f36::) joined #osdev
19:19:44 --- quit: Wild (Ping timeout: 240 seconds)
19:19:45 --- quit: Olgierd (Ping timeout: 240 seconds)
19:19:46 --- quit: marky (Ping timeout: 240 seconds)
19:19:46 --- quit: transistor (Ping timeout: 240 seconds)
19:19:46 --- quit: oshogbo (Ping timeout: 240 seconds)
19:19:47 --- quit: cruxeternus (Ping timeout: 240 seconds)
19:19:48 --- quit: pisculichi (Ping timeout: 240 seconds)
19:19:49 --- quit: radens (Ping timeout: 240 seconds)
19:19:49 --- quit: Gaudasse (Ping timeout: 240 seconds)
19:19:49 --- quit: voiceftp (Ping timeout: 240 seconds)
19:19:49 --- quit: catern (Ping timeout: 240 seconds)
19:19:50 --- quit: sixand (Ping timeout: 240 seconds)
19:19:50 --- quit: tadni_ (Ping timeout: 240 seconds)
19:19:54 --- quit: ZeDestructor (Ping timeout: 240 seconds)
19:19:54 --- quit: dengke (Ping timeout: 240 seconds)
19:19:55 --- quit: port443 (Ping timeout: 240 seconds)
19:19:55 --- quit: empy (Ping timeout: 240 seconds)
19:19:56 --- quit: Plazma (Ping timeout: 240 seconds)
19:19:58 --- quit: Kydd (Ping timeout: 240 seconds)
19:19:58 --- quit: zopsi (Ping timeout: 240 seconds)
19:20:01 --- join: lansiir (~oldtopman@c-107-2-209-146.hsd1.co.comcast.net) joined #osdev
19:20:03 --- quit: dustinm` (Ping timeout: 260 seconds)
19:20:03 --- quit: Nokurn (Ping timeout: 260 seconds)
19:20:04 --- quit: iknosis (Ping timeout: 260 seconds)
19:20:04 --- quit: _mjg (Ping timeout: 260 seconds)
19:20:05 --- quit: Guest21615 (Ping timeout: 260 seconds)
19:20:07 --- quit: bslsk05 (Ping timeout: 260 seconds)
19:20:07 --- quit: nwm (Ping timeout: 260 seconds)
19:20:08 --- quit: miselin (Ping timeout: 260 seconds)
19:20:08 --- quit: zeroSignal (Ping timeout: 260 seconds)
19:20:10 --- quit: tux3 (Ping timeout: 260 seconds)
19:20:11 --- quit: zxq2 (Ping timeout: 260 seconds)
19:20:11 --- quit: xedniv (Ping timeout: 260 seconds)
19:20:11 --- quit: jp (Ping timeout: 260 seconds)
19:20:12 --- quit: pie_ (Ping timeout: 260 seconds)
19:20:13 --- quit: doug16k (Ping timeout: 260 seconds)
19:20:14 --- quit: oldtopman (Ping timeout: 260 seconds)
19:20:18 --- join: Nokurn (~Nokurn@71-95-52-160.dhcp.rvsd.ca.charter.com) joined #osdev
19:20:21 --- nick: sixand1 -> sixand
19:20:22 --- nick: ZeDestructor_ -> ZeDestructor
19:20:22 --- nick: tux3_ -> tux3
19:20:22 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
19:20:22 --- join: doug16k_ (~dougx@172-97-186-251.cpe.distributel.net) joined #osdev
19:20:23 --- join: radens (kronquii@shell.onid.oregonstate.edu) joined #osdev
19:20:23 --- join: Guest21615 (~testerr@206.189.79.99) joined #osdev
19:20:24 --- join: Gaudasse (~Gaudasse@bitwise.fr) joined #osdev
19:20:25 --- join: catern_ (~catern@catern.com) joined #osdev
19:20:25 --- quit: lansiir (Changing host)
19:20:25 --- join: lansiir (~oldtopman@unaffiliated/oldtopman) joined #osdev
19:20:33 --- join: Olgierd (~Olgierd@ns364739.ip-91-121-210.eu) joined #osdev
19:20:37 --- join: dengke (~dengke@60.247.85.82) joined #osdev
19:20:37 --- quit: dengke (*.net *.split)
19:20:38 --- quit: radens (*.net *.split)
19:20:39 --- quit: lansiir (*.net *.split)
19:20:48 --- join: miselin (~miselin@115.0.198.104.bc.googleusercontent.com) joined #osdev
19:21:14 --- nick: zopsi_ -> zopsi
19:21:47 --- join: NaNkeen (~nankeen@61.6.61.42) joined #osdev
19:22:11 <sircmpwn> did a little project tonight
19:22:15 <sircmpwn> https://git.sr.ht/~sircmpwn/hiti/tree/README
19:22:25 <sircmpwn> not that anyone was asking for a "TI calculators barebones"
19:22:39 --- quit: Olgierd (Changing host)
19:22:39 --- join: Olgierd (~Olgierd@unaffiliated/olgierd) joined #osdev
19:22:44 --- nick: miselin -> Guest44347
19:22:54 <Mutabah> :)
19:23:07 <Mutabah> But someone might use it, so you're doing them a service
19:23:26 --- join: oshogbo (~oshogbo@80-219-208-230.dclient.hispeed.ch) joined #osdev
19:24:43 --- quit: Guest44347 (Changing host)
19:24:43 --- join: Guest44347 (~miselin@pdpc/supporter/student/pcmattman) joined #osdev
19:25:15 <klange> finally i can port toaruos to my ti83se
19:25:33 <sircmpwn> you'll have to rewrite it in C89 first I'm afraid
19:26:00 <klange> ah, shucks, maybe I'll just go find a toolchain for the nspire instead
19:26:15 --- join: marky (~marky@198.100.153.47) joined #osdev
19:26:15 --- join: dengke (~dengke@60.247.85.82) joined #osdev
19:26:15 --- join: radens (kronquii@shell.onid.oregonstate.edu) joined #osdev
19:26:15 --- join: lansiir (~oldtopman@unaffiliated/oldtopman) joined #osdev
19:26:16 <sircmpwn> aka a stock ARM compiler
19:26:26 --- quit: lansiir (Max SendQ exceeded)
19:26:29 <sircmpwn> lemme hook you up with a linux bootloader to work from
19:26:30 <klange> I have an original nspire CAS from when they first came out <3
19:26:35 <sircmpwn> me too!
19:26:44 <sircmpwn> https://git.sr.ht/~sircmpwn/hiti/tree/README
19:26:47 <sircmpwn> https://github.com/tangrs/nspire-linux-loader2 *
19:26:52 --- join: lansiir (~oldtopman@c-107-2-209-146.hsd1.co.comcast.net) joined #osdev
19:26:54 <sircmpwn> details on booting linux https://hackspire.org/index.php/Linux
19:27:19 --- quit: lansiir (Changing host)
19:27:19 --- join: lansiir (~oldtopman@unaffiliated/oldtopman) joined #osdev
19:27:24 <klange> If I can find the thing in my storage unit when I'm in the US in a few weeks, I'll slap a Linux on it.
19:27:45 --- join: bslsk05 (~bslsk@puckipedia.com) joined #osdev
19:28:29 --- quit: variable (Ping timeout: 276 seconds)
19:28:48 <sircmpwn> why slap a linux on it when you could slap a toaruos on it
19:29:00 <klange> because linux already has an arm port that is mature and well supported, for one ;)
19:29:03 <sircmpwn> although given that your desktop is swrast-driven... good luck
19:29:13 <klange> the toaruos arm port barely has a thing to spit out debug text
19:29:44 <klange> sircmpwn: I'm sure it'd run much better on the small grayscale display of the nspire classic
19:29:57 <sircmpwn> I dunno if the framebuffer works on that one
19:30:06 <sircmpwn> well, I'm being silly
19:30:22 <sircmpwn> the framebuffer only works on linux cause they wrote a driver for it, you'd have to too
19:30:24 <sircmpwn> it's memory mapped
19:30:25 --- join: iknosis (~iknosis@185.183.104.140) joined #osdev
19:30:26 --- join: jp (ayy@youlosethega.me) joined #osdev
19:31:21 --- join: Goplat (~Goplat@50-0-95-84.dsl.dynamic.fusionbroadband.com) joined #osdev
19:31:23 --- quit: Goplat (Changing host)
19:31:23 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
19:31:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:31:37 --- join: Wild (~Wild@archlinux/trusteduser/wild) joined #osdev
19:32:00 --- nick: catern_ -> catern
19:32:49 --- join: xedniv (~xedniv@arms.trafficking.cn) joined #osdev
19:32:49 --- quit: xedniv (Changing host)
19:32:50 --- join: xedniv (~xedniv@unaffiliated/moldenauer) joined #osdev
19:34:22 <doug16k_> memory mapped framebuffers are my favourite
19:35:16 <doug16k_> I've had to bitbang displays from a microcontroller over 2 or 3 wires, I'm serious ;)
19:35:28 <sircmpwn> my osdev claim to fame has to do something similar
19:35:35 <sircmpwn> I have to sling pixels through ports
19:35:56 <sircmpwn> see src/00/display.S in my first link ;)
19:38:42 --- quit: korans (Ping timeout: 240 seconds)
19:44:40 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
19:45:44 --- quit: JusticeEX (Ping timeout: 256 seconds)
19:45:49 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
19:51:07 --- quit: dbittman_ (Remote host closed the connection)
19:51:34 --- quit: S_Gautam (Quit: Connection closed for inactivity)
19:53:13 --- join: nicht (~nicht@2804:7f1:2080:5ccc:9a91:91c7:ad26:d430) joined #osdev
19:59:19 --- quit: zeus1 (Ping timeout: 265 seconds)
20:02:48 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
20:05:32 --- quit: variable (Ping timeout: 276 seconds)
20:08:36 --- quit: ^Inuyasha^ (Ping timeout: 256 seconds)
20:08:43 --- quit: nj0rd (Ping timeout: 256 seconds)
20:08:47 --- quit: drakonis (Remote host closed the connection)
20:12:40 --- join: ^Inuyasha^ (~quassel@vmi86808.contabo.host) joined #osdev
20:14:15 --- join: NightBlade (~user@ip-173-247-149-50.user.start.ca) joined #osdev
20:14:54 --- join: empy (~l@24.35.93.176) joined #osdev
20:14:55 --- quit: empy (Changing host)
20:14:55 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
20:15:34 --- quit: bemeurer (Ping timeout: 248 seconds)
20:20:17 --- quit: tacco| ()
20:21:56 --- join: nj0rd (~nj0rd@200116b845ed1700039f64cfc5c12f89.dip.versatel-1u1.de) joined #osdev
20:22:56 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
20:25:05 --- quit: doug16k_ (Remote host closed the connection)
20:26:42 --- quit: j00ru (Ping timeout: 240 seconds)
20:26:59 --- quit: oshogbo (Ping timeout: 276 seconds)
20:28:13 --- quit: Gynvael (Ping timeout: 268 seconds)
20:33:06 --- quit: NaNkeen (Ping timeout: 264 seconds)
20:33:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:36:42 --- quit: trout (Ping timeout: 240 seconds)
20:37:43 --- join: NaNkeen (~nankeen@61.6.61.42) joined #osdev
20:38:30 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:38:40 --- join: oshogbo (~oshogbo@80-219-208-230.dclient.hispeed.ch) joined #osdev
20:38:52 --- join: j00ru (~j00ru@80-219-208-230.dclient.hispeed.ch) joined #osdev
20:39:27 --- join: Gynvael (~gynvael@80-219-208-230.dclient.hispeed.ch) joined #osdev
20:39:56 --- quit: pie__ (Ping timeout: 244 seconds)
20:42:06 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
20:42:11 --- join: stephen77 (~stephen@142.167.171.31) joined #osdev
20:42:11 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-pksrvwbnahtzvwwr) joined #osdev
20:43:14 --- quit: zeus1 (Client Quit)
20:50:10 <variable> http://shape-of-code.coding-guidelines.com/2018/07/10/instructions-that-cpus-dont-need-to-support/
20:50:12 <bslsk05> ​shape-of-code.coding-guidelines.com: The Shape of Code » Instructions that cpus don’t need to support
20:50:19 <ybyourmom> HCF?
20:50:41 <variable> ybyourmom: HCF is required for printers to work
20:50:50 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
20:51:09 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:52:29 <ybyourmom> and IoT enabled cigarette lighters I guess?
20:53:52 <bcos> There's several variations of "single instruction set" CPUs, which proves that no specific instruction is necessary
20:55:53 --- quit: nicht (Ping timeout: 256 seconds)
20:58:00 <variable> bcos: "to be turing complete" and "to be useful" and "can be useful" are all different
20:58:10 <variable> even "to be optimal" or "to be helpful"
20:58:26 <variable> or "to be worth the cost of implementing"
20:59:52 * bcos defines "need" as something people would (literally) die without, like air, water, pizza, ..
21:01:13 <bcos> (in other words "Instructions that cpus don’t need to support" is very different to "Instructions that are least useful")
21:01:41 <variable> bcos: just add any of the "to ..." statements above
21:04:14 --- join: flacks (~jean@184.91.69.131) joined #osdev
21:04:36 --- quit: chao-tic (Ping timeout: 268 seconds)
21:05:24 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
21:05:42 --- quit: spare (Ping timeout: 248 seconds)
21:08:34 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:08:52 --- quit: NaNkeen (Ping timeout: 244 seconds)
21:08:55 --- quit: variable (Ping timeout: 265 seconds)
21:16:23 --- join: NaNkeen (~nankeen@61.6.132.35) joined #osdev
21:19:02 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
21:20:25 --- join: M1cha (~M1cha@2a02:908:5a3:da80:7a8d:2699:26c0:ba14) joined #osdev
21:21:03 --- quit: flacks (Read error: Connection reset by peer)
21:25:07 --- join: doug16k (~dougx@172-97-186-251.cpe.distributel.net) joined #osdev
21:25:24 --- quit: alyptik (Ping timeout: 244 seconds)
21:28:11 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
21:31:40 <jjuran> The H in HCF implies that it only works once
21:31:45 <jjuran> which is bad for concurrency
21:34:17 <klange> literally the only thing I know of that HCF expands to is "halt and catch fire"
21:34:49 --- quit: NaNkeen (Ping timeout: 268 seconds)
21:35:02 <klange> but halt just means wait for interrupt, so obviously you can get an interrupt after halting and catching fire
21:35:12 <Mutabah> A very useful feature when your computer doubles as a space heater
21:35:53 --- quit: epony (Quit: QUIT)
21:36:21 <klange> I hear that due to the way the microcode on Intel CPUs is implemented, the halt and catch fire isn't atomic - and due to the pipelining, you can't be sure whether it halt OR catch fire first.
21:36:39 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
21:36:58 <bcos> Superscalar - probably halts in one pipeline while catching fire in another
21:37:03 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:38:06 --- join: flacks (~jean@184.91.69.131) joined #osdev
21:38:52 --- nick: pisculic1i -> pisculichi
21:39:07 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
21:39:12 --- quit: pisculichi (Changing host)
21:39:12 --- join: pisculichi (pisculichi@unaffiliated/pisculichi) joined #osdev
21:40:42 --- quit: trout (Ping timeout: 240 seconds)
21:46:46 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
21:51:43 --- part: flacks left #osdev
21:53:12 <jjuran> I was under the impression that it culd only catch one fire at a time
21:53:16 <jjuran> *could
21:54:00 --- quit: zeus1 (Ping timeout: 260 seconds)
21:56:59 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
21:57:55 --- quit: light2yellow (Quit: light2yellow)
22:01:30 --- quit: tadni (Remote host closed the connection)
22:03:44 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-glztunroxremescl) joined #osdev
22:05:31 --- quit: chao-tic (Quit: WeeChat 1.0.1)
22:07:36 --- join: NaNkeen (~nankeen@61.6.132.35) joined #osdev
22:08:26 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
22:09:29 --- quit: hmmmm (Remote host closed the connection)
22:12:17 --- quit: variable (Ping timeout: 276 seconds)
22:13:35 <geist> also intel cpus will speculatively catch fire some times
22:14:04 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
22:18:07 <klange> Don't worry, if the actual evualation wouldn't have caught fire, the pipeline will extinguish the flames.
22:19:08 --- join: antkit (uid256318@gateway/web/irccloud.com/x-pbihvbmrrczekfvu) joined #osdev
22:20:09 --- quit: bauen1 (Remote host closed the connection)
22:22:15 <Affliction> IoT cigarette lighters... Excellent, because literally starting fires over the internet is an excellent idea that will never, ever, go wrong, at all, ever.
22:25:37 --- quit: M1cha (Remote host closed the connection)
22:26:20 --- quit: smeso (Remote host closed the connection)
22:31:15 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
22:31:16 --- join: smeso (~smeso@unaffiliated/smeso) joined #osdev
22:36:55 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
22:40:45 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
22:43:39 --- quit: trout (Ping timeout: 265 seconds)
22:50:08 <jjuran> Affliction: https://twitter.com/burnedyourtweet
22:50:10 <bslsk05> ​twitter.com: Burned Your Tweet (@burnedyourtweet) | Twitter
22:50:32 <jjuran> https://www.theverge.com/tldr/2017/3/28/15102170/donald-trump-tweets-robot-burning-twitter
22:50:33 <bslsk05> ​www.theverge.com: A robot is burning every one of Donald Trump’s tweets so you don’t have to - The Verge
22:51:18 <bcos> Someone skipped the "root cause analysis" on that...
22:52:48 --- quit: NaNkeen (Ping timeout: 240 seconds)
22:54:41 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
23:00:32 <Affliction> Yep, I'd certainly leave that running unattended! No problem at all!
23:11:25 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
23:15:20 --- quit: variable (Ping timeout: 276 seconds)
23:17:13 --- join: NaNkeen (~nankeen@61.6.132.35) joined #osdev
23:17:32 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
23:20:25 --- quit: S_Gautam (Quit: Connection closed for inactivity)
23:21:18 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:25:48 --- quit: myvar (Ping timeout: 240 seconds)
23:26:49 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
23:26:55 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:27:58 --- quit: myvar (Remote host closed the connection)
23:31:30 --- quit: nortega (Ping timeout: 250 seconds)
23:32:13 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:35:21 --- quit: hiei (Quit: ...)
23:39:23 --- quit: angel0xff (Ping timeout: 276 seconds)
23:39:36 --- quit: NaNkeen (Ping timeout: 260 seconds)
23:42:29 --- quit: manzerbredes (Ping timeout: 256 seconds)
23:45:04 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
23:45:20 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
23:46:12 --- quit: apetresc (Ping timeout: 240 seconds)
23:47:11 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:48:12 --- quit: trout (Ping timeout: 240 seconds)
23:50:49 --- join: NaNkeen (~nankeen@61.6.132.35) joined #osdev
23:52:18 --- quit: myvar (Ping timeout: 264 seconds)
23:53:45 --- join: apetresc (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
23:53:48 --- quit: bemeurer (Quit: WeeChat 2.1)
23:53:49 --- quit: shymega (Quit: Peace out.)
23:59:59 --- log: ended osdev/18.07.09