Search logs:

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=5&d=20

Sunday, 20 May 2018

00:00:00 --- log: started osdev/18.05.20
00:00:04 <Drakonis[m]> how about duke
00:00:09 <_mjg_> meh
00:00:22 <_mjg_> half life is the gold standard for me for single player
00:00:28 <_mjg_> shooter
00:00:40 <Drakonis[m]> there's a movie with john cena now
00:00:40 <geist> yeah totally. half life was pretty outstanding at the time
00:00:41 <Belxjander> PORTAL.... the cake is a lie! :)
00:01:02 <geist> i remember staying up all weekend playing HL when it first came out
00:01:05 <Belxjander> GLaDOS crazy with extra wtf? as a side dish :)
00:01:22 <geist> forget if it was partially accelerated. i had a voodoo2 at the time, and was jumping at the time to use anything that support glide
00:01:54 * Belxjander actually got Portal 1 for free when buying Portal 2 with some crazy massive mark down release day thing
00:02:11 <geist> it came in the orange box
00:02:13 * Belxjander actually got both games with Portal 2 at 90% or 95% off the price
00:02:49 <_mjg_> yee half life was pretty awesome
00:02:52 <Drakonis[m]> orange box man? legit best deal
00:02:59 <_mjg_> which reminds me i never finished opposing forces
00:03:13 <_mjg_> and never played the other on
00:03:15 <_mjg_> e
00:03:24 <Drakonis[m]> portal is a game that deserves an open source remake
00:03:50 <Drakonis[m]> just for the ability to do wild things with the portal gun
00:03:59 <Belxjander> Drakonis[m]: I'm working on something at the moment which would support that happening...
00:04:37 <Drakonis[m]> hmm really? that's cool
00:04:52 <Drakonis[m]> fps engine i suppose?
00:05:01 * Belxjander also has one seriously crazy level concept that NEEDS a kind of crazy to finish the design of
00:05:04 <geist> nah, it's a MUD
00:05:42 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
00:05:48 <_mjg_> haha, muds
00:05:56 <_mjg_> i was pondering playing one
00:06:08 <geist> i was actually just pondering the same thing
00:06:09 <Drakonis[m]> hellmoo.
00:06:09 <_mjg_> i asked a friend who played what this is all about
00:06:26 <Belxjander> First-Person 3Dview with RPG character elements... so something of an FPS/MUD crossover... and done without any real constraints on level design
00:06:27 <geist> and not i'm trying to remember what the name of that crazy thing is you telnet into and then 'hack' other computers with
00:06:32 <_mjg_> at least in his corner they were playing a different game: how to hack without getting spotted
00:06:36 <geist> it's hard to tell if it's meta or what
00:06:50 <Drakonis[m]> hacknet?
00:07:17 <geist> hmm, doesn't look like it, though this may be fun too
00:07:28 <geist> telehack
00:07:46 <geist> http://telehack.com/ i have no real idea how far this rabbit hole goes
00:07:47 <bslsk05> ​telehack.com: Telehack
00:07:56 <_mjg_> huh
00:08:02 <_mjg_> in that spirit, anyone tried wargames?
00:08:03 <geist> you can also telnet to it
00:08:07 <_mjg_> i mean i'm pretty sure many of you did
00:08:26 <_mjg_> but *competing* in the area is a different story
00:08:49 * Belxjander has only really done dungeon crawling in Isometric (Diablo / Hellfire) or FPS styles
00:09:20 * geist also has fond memories of ultima underworld
00:09:46 <geist> it was a bit ahead of its time, needed a beefy machine
00:09:46 <Belxjander> Ha! my wife still has an original JP edition of that
00:10:32 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
00:10:36 --- quit: awang (Ping timeout: 260 seconds)
00:10:55 <_mjg_> ok that's it, i'm going to play some super mario
00:11:06 <geist> i need to finish up Dad of War
00:11:29 <geist> http://i0.kym-cdn.com/photos/images/original/001/365/290/a28
00:12:36 <Drakonis[m]> BOY
00:12:51 <geist> yessir
00:12:57 --- quit: dbittman_ (Ping timeout: 276 seconds)
00:13:07 <_mjg_> good grief, check out this smp bug: it disappears with high enough level of contentnion
00:13:11 <_mjg_> :[
00:13:17 <geist> you foudn it in super mario?
00:13:30 <Drakonis[m]> http://www.underworldascendant.com/
00:13:31 <bslsk05> ​www.underworldascendant.com: Underworld Ascendant – The action-RPG designed for player creativity
00:13:53 <Drakonis[m]> i hear you like underworld
00:16:13 <geist> yeah
00:16:37 <geist> years ago too i found some app that decodes and visualizes the map in underworld 1 and 2
00:16:59 <geist> it turns otu it's basically just a set of 64x64 levels, not true 3d, but it has up and down ramps and whatnot and looks pretty close
00:17:12 <geist> er 8 leves of 64x64 blocks
00:17:21 <geist> and one of a bunch of various configurations of block
00:17:53 <Drakonis[m]> the stuff game folks did then was cool
00:18:07 --- join: quc (~quc@87.116.237.92) joined #osdev
00:18:07 <geist> it was leapfrogging, yeah
00:18:14 <geist> every few years something truly new came out, it was pretty neat
00:18:38 <geist> somewhere in the early nineties was the quintessential star control 2
00:19:40 <Drakonis[m]> ah star control, i hope the devs sort out their troubles with stardock so they can make a new one
00:19:59 <geist> oh now i didn't know this: the team that did ultima underworld 1 and 2 then went on to do system shock the next year
00:20:05 <geist> now it's all clear how they're connected
00:21:23 <Drakonis[m]> it's all connected maaan
00:21:34 <geist> whoa man...
00:22:00 <_mjg_> on a more serious note and a very different spin, i'm looking for interesting 'general' reads. examples: cargo cult science by feynman or http://chem.tufts.edu/answersinscience/relativityofwrong.htm
00:22:01 <bslsk05> ​chem.tufts.edu: Asimov - The Relativity of Wrong
00:22:16 <_mjg_> any suggestions?
00:22:20 <Drakonis[m]> six degrees of warren spector
00:23:41 <Drakonis[m]> now, serious reads you say?
00:24:04 <Drakonis[m]> science related right?
00:24:59 <Drakonis[m]> otherwise i'd give you some excellent series of books to read
00:25:03 --- quit: BartAdv (Quit: Connection closed for inactivity)
00:25:26 --- quit: elevated (Quit: bye)
00:28:17 <Drakonis[m]> like discworld
00:29:32 <_mjg_> Drakonis[m]: short pieces, does not have to be science related, just someone smart writing something insighstful
00:29:32 <KernelBloomer> where can I find good security material to read
00:29:34 <KernelBloomer> for OSdev?
00:29:37 <KernelBloomer> hnmmmM!?
00:29:39 <_mjg_> what security?
00:30:06 <_mjg_> the subject is broad for lack of a better word
00:31:18 <_mjg_> since you are asking on *osdev*, https://www.amazon.com/Guide-Kernel-Exploitation-Attacking-Core/dp/1597494860
00:31:21 <bslsk05> ​www.amazon.com: A Guide to Kernel Exploitation: Attacking the Core: Enrico Perla B.Sc. Computer Science University of Torino M.Sc. Computer Science Trinity College Dublin, Massimiliano Oldani: 9781597494861: Amazon.com: Books
00:31:30 <Drakonis[m]> okay so it's out of question
00:32:28 <_mjg_> KernelBloomer: in general that would be phrack and pax team materials
00:32:51 <KernelBloomer> but they are not accessible anymore
00:32:53 <KernelBloomer> in grsecurity right
00:33:01 <_mjg_> https://pax.grsecurity.net/docs/
00:33:02 <bslsk05> ​pax.grsecurity.net: Documentation for the PaX project
00:33:12 <geist> okay, so this is very NSFW but i discovered a band today: Steel Panther
00:33:29 <geist> they're extremely raunchy modern day 80s hair metal band
00:33:38 <_mjg_> huh
00:34:25 <KernelBloomer> _mjg_, any other links
00:34:26 <Drakonis[m]> hair metal still exists? huh
00:35:11 <geist> it's pretty raunchy and misogynist in the way 80s hair metal was
00:35:28 <_mjg_> KernelBloomer: depends, what ar eyou looking for
00:35:57 <KernelBloomer> _mjg_, grsecurity is not open anymore
00:36:00 <KernelBloomer> PaX is part of it
00:36:05 <KernelBloomer> and its dead in arm
00:36:06 <Drakonis[m]> i still go whoa when i remember discworld has 45 books and the author is super awesome but has passed away
00:36:33 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
00:36:34 <Drakonis[m]> was 80s metal ever not weird?
00:37:43 <_mjg_> KernelBloomer: again, what are you looking for
00:38:03 <KernelBloomer> _mjg_, exploit mitigations and hardening in general
00:38:04 <_mjg_> if you are looking for docs how exploitation mitigation features are implemented in oeprating systems
00:38:04 <KernelBloomer> in code
00:38:10 <_mjg_> or how to attacak them, see above
00:38:11 <KernelBloomer> yes docs to learn
00:38:20 <_mjg_> well then you got the links
00:38:22 <KernelBloomer> PaX docs are enough for osdev security?
00:38:41 <_mjg_> eh, here are some extra keywords:
00:38:55 <_mjg_> return oriented programming, capsicum, selinux, MAC
00:39:05 <_mjg_> ASLR, DEP, SMAP, SMEP
00:39:14 <_mjg_> for any of these you will ez find a lot of stuff
00:39:26 <_mjg_> the links i already gave you should keep you busy for the foreseable future
00:39:36 <KernelBloomer> you gave me PaX link only
00:39:45 <_mjg_> i also linked a book
00:39:57 <KernelBloomer> where
00:40:01 <KernelBloomer> oh ok
00:40:10 <Drakonis[m]> agh i'll go to sleep, gnight
00:40:13 <KernelBloomer> _mjg_, isnt it outdated? the book date is old
00:40:21 <_mjg_> it is not *oudated*
00:40:37 <_mjg_> there are new mitigations no doubt
00:40:44 <KernelBloomer> most of the hacking is already mitigated
00:40:47 <Drakonis[m]> http://www.gnuterrypratchett.com/ no relation whatsoever with gnu the project
00:40:48 <_mjg_> but the book is more than useful
00:40:48 <bslsk05> ​www.gnuterrypratchett.com: GNU Terry Pratchett
00:41:07 --- join: bcos_ (~bcos@58.170.158.30) joined #osdev
00:41:12 <_mjg_> are you looking for a guide how to *attack* a recent linux kernel or something?
00:41:16 <_mjg_> if so, i don't have anything
00:42:25 <_mjg_> i mean nothing off hand, you will probably be best served by asking on the grsec channel
00:42:28 <_mjg_> but prepare yousrelf :>
00:42:42 <KernelBloomer> _mjg_, I wanna contribute in security for linux kernel
00:42:45 <KernelBloomer> or any open source
00:42:55 <KernelBloomer> grsec is invite only
00:43:45 <_mjg_> i don't think security is a good area to contribute to for a beginner
00:44:17 <_mjg_> grsecurity has a channel on a different network, oftc.net afair
00:44:23 --- quit: bcos (Ping timeout: 256 seconds)
00:45:18 <KernelBloomer> ahan I see
00:46:30 <_mjg_> note you are setting yourself up to get flamed by spender
00:46:33 <_mjg_> :->
00:46:45 <KernelBloomer> grsec is paid only
00:46:46 <KernelBloomer> right
00:46:49 <KernelBloomer> not free anymore
00:46:57 <KernelBloomer> and he also sued many linux security geeks
00:46:58 <KernelBloomer> lol
00:52:43 <_mjg_> he does seem to have a beef with several people
00:53:12 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
00:53:50 <jjuran> IMHO, an Atari ST isn't useful for anything that involves keyboard use.
00:56:28 <jjuran> Belxjander: https://xkcd.com/606/ :-)
00:56:28 <bslsk05> ​xkcd - Cutting Edge
00:57:03 --- quit: sprocklem (Ping timeout: 256 seconds)
00:57:40 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
01:06:02 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
01:06:54 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
01:07:31 --- quit: zeus1 (Ping timeout: 268 seconds)
01:09:26 --- quit: dan|ic (Quit: Connection closed for inactivity)
01:11:16 --- quit: ALowther (Ping timeout: 260 seconds)
01:18:00 --- quit: bork (Ping timeout: 268 seconds)
01:18:58 --- quit: KernelBloomer (Quit: Leaving)
01:20:09 --- join: Kimundi_ (~Kimundi@i577A91E4.versanet.de) joined #osdev
01:20:21 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
01:36:25 --- quit: hmmmm (Remote host closed the connection)
01:38:04 --- quit: Goplat (Remote host closed the connection)
01:43:45 --- join: Asu (~sdelang@70.42.136.77.rev.sfr.net) joined #osdev
01:50:00 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
01:53:50 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
02:06:30 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
02:08:48 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
02:10:49 --- quit: awang (Ping timeout: 240 seconds)
02:12:20 <klange> I should port my help document system / janky as fuck web browser to C.
02:12:45 <z0ttel> why not brainfuck?
02:13:05 <klange> Because brainfuck would serve no purpose in my software ecosystem?
02:13:54 --- quit: zeus1 (Quit: WeeChat 2.1)
02:13:56 <z0ttel> Oh - right.
02:14:12 <klange> Because it's currently Python as I prototype in Python and wrote my entire desktop environment in Python for my original OS but am working from scratch without a Python interpreter this time around and it's either C or a half-baked C++ that's missing the standard library?
02:14:35 <klange> Because I'm a masochist who actually enjoys writing things in C?
02:14:48 <z0ttel> I was just trolling - no need to worry about it o.o
02:17:45 --- join: m_t (~m_t@p5DDA3191.dip0.t-ipconnect.de) joined #osdev
02:17:47 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:4ceb:1292:a33e:32d2) joined #osdev
02:44:38 --- quit: Brain (Ping timeout: 250 seconds)
02:53:15 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
02:55:35 --- quit: `Guest00000 (Ping timeout: 248 seconds)
03:02:56 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:03:11 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:03:18 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:05:38 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
03:07:18 --- join: `Guest00000 (~user@37.113.180.34) joined #osdev
03:07:52 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
03:22:22 --- quit: elevated (Ping timeout: 256 seconds)
03:23:56 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:24:03 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:24:41 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:30:03 --- join: Brain (~brain@brainwave.brainbox.cc) joined #osdev
03:30:04 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:30:24 --- quit: JonRob (Quit: Lost terminal)
03:30:34 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
03:32:17 --- quit: JonRob (Client Quit)
03:32:29 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
03:33:13 --- quit: [Brain] (Ping timeout: 240 seconds)
03:33:52 --- quit: JonRob (Client Quit)
03:34:54 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:34:54 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:36:16 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
03:39:55 --- quit: JonRob (Client Quit)
03:40:10 --- join: JonRob (jon@gateway/vpn/privateinternetaccess/jonrob) joined #osdev
03:53:37 --- join: S_Gautam (3bb6feb7@gateway/web/freenode/ip.59.182.254.183) joined #osdev
03:57:45 --- quit: ljc (Quit: ayy)
04:02:23 --- quit: S_Gautam (Quit: brb)
04:07:13 --- join: akasei (~akasei@viscon.wataha.net) joined #osdev
04:07:58 <akasei> hey! quick Q, how to connect VGA to PCI slot in Qemu? i know how to do it in Bochs "pci: enabled=1, chipset=i440fx, slot1=pcivga"
04:08:04 <akasei> simple "-vga std" not working
04:08:25 --- quit: m3nt4L (Remote host closed the connection)
04:08:36 --- quit: zeus1 (Ping timeout: 260 seconds)
04:08:37 <klange> akasei: what about that isn't working?
04:08:49 <akasei> i can't find in Qemu BAR0
04:08:52 <akasei> for VGA
04:08:59 <akasei> there is no device
04:09:30 <klange> What device are you looking for?
04:09:36 <akasei> 0x1111 0x1234
04:09:45 <akasei> VBE
04:09:49 <klange> It should be there. Are you sure you scanning correctly?
04:09:52 <akasei> yes
04:09:57 <akasei> on bochs it working
04:10:13 <klange> Doesn't mean it'll work in Qemu if your PCI scanning is faulty.
04:10:34 <akasei> PCI scanning is working good, almost all other devices are scanned properly :)
04:10:53 <akasei> or there is another vendor device in qemu?
04:11:16 <klange> not with -vga std, which has been the default for a few years now
04:11:25 <klange> (formerly, the default was a Cirrus chipset)
04:12:00 <klange> What other configuration arguments are you giving to qemu?
04:12:09 <akasei> nothing more :)
04:12:25 <akasei> see: qemu-system-x86_64 -drive file=build/disk.raw,media=disk,format=raw -m 2 -vga std
04:12:40 <klange> -m 2?
04:12:44 <akasei> memory 2 MiB
04:12:50 <klange> you are giving your VM... 2MiB of RAM?
04:12:53 <akasei> yes
04:13:02 <akasei> i dont need more
04:13:04 <klange> your framebuffer is nonexistent
04:13:18 <Mutabah> klange: Does that count towards the video too?
04:13:44 <akasei> video memory is separeted from RAM
04:13:59 <Mutabah> Try without the `-m`...
04:14:07 <Mutabah> wfm without it
04:14:11 <akasei> ok, so it will be 128 MiB
04:14:15 <klange> why are you specifying 2MB of RAM? is that even a valid amount on x86-64?
04:14:27 <Mutabah> klange: I'd assume it's valid
04:14:32 <akasei> yes vaild
04:14:33 <Mutabah> useful? No, but valid probaby
04:14:40 <akasei> and no chagne withous -m
04:14:44 <akasei> withoud*
04:14:51 <Mutabah> What version of qemu?
04:14:53 <akasei> 2.21.0
04:15:02 <akasei> tfu
04:15:04 <akasei> 2.12.2
04:15:07 <akasei> 2.12.0
04:15:08 <akasei> sorry
04:15:19 <Mutabah> Your PCI code is probably buggy
04:15:24 <akasei> hmm
04:15:31 <akasei> i don't fink so, but i can show code
04:15:37 <akasei> it's assembly
04:16:07 <Mutabah> I'm runing 2.8.0, device 1234:1111 shows up at address 0x10
04:17:02 <klange> https://i.imgur.com/xV4RmyX.png
04:17:34 <Mutabah> looks like the same for klange
04:17:48 <akasei> ok i need some time to check it up
04:18:29 <klange> If I send you an ISO to test, will you run it?
04:18:36 <akasei> yes
04:18:39 <klange> https://toaruos.org/image.iso
04:19:09 <klange> just `-cdrom image.iso` though I always recommend KVM (`-enable-kvm`) with my OS
04:19:21 <akasei> ok
04:19:34 <klange> select the second boot option, login as root/toor, run kdebug, then pci
04:20:20 <akasei> there is no VGA :) let me take screenshot
04:20:37 <klange> amazing, something may actually be wrong with your qemu setup :)
04:20:45 <akasei> Manjaroo qemu
04:20:50 <klange> did you build from source? are you missing the VGA bios?
04:21:14 <klange> I'm not actually sure the BIOS is necessary, but it's a possible cause...
04:21:48 <akasei> ok
04:21:49 <akasei> found
04:21:54 <akasei> i missread
04:22:06 <akasei> :(
04:22:59 <akasei> 00:02.0
04:24:04 <akasei> this is my simple PCI read (polish only) https://pastebin.com/Li2ANnF9
04:24:04 <bslsk05> ​pastebin.com: [ASM (NASM)] ;============================================================================ ; - Pastebin.com
04:24:47 <akasei> andi t worked so far :( i will try to find the bug
04:24:56 <akasei> thx, for your time
04:25:20 <Mutabah> That's just the read method, it's kinda hard to get wrong (but maybe set a breakpoint on it and check that the values are right)
04:25:36 <Mutabah> The more likely bug is in the actual enumeration
04:26:14 <Mutabah> ... why are you using `rol` instead of `shl`?
04:26:35 <Mutabah> also, line 32 looks suspect - shifting left by 6 bits just before doing a 2 bit shift.
04:27:02 <Mutabah> the 2bit shift looks like the final multiply by 4 for alignment/words, but that 6 looks odd
04:27:09 <akasei> i'm rolling to set proper value in low register, and not lost other informations
04:28:08 <akasei> but it is very strange beacuse with this procesure i properly configures E1000
04:28:12 <akasei> configured*
04:29:07 <akasei> ok, let me check it properly (need some time
04:39:58 <akasei> thank you :)
04:40:05 <akasei> there was bug
04:40:17 <akasei> now i corrected place of device bus and function
04:40:39 <akasei> https://pastebin.com/aWQd7njb
04:40:39 <bslsk05> ​pastebin.com: [ASM (NASM)] ; ustaw numer rejestru na miejsce rol eax, 2 ; włącz bit 31 or eax, 0 - Pastebin.com
04:41:11 <akasei> i prepared bus:0 device:2 function:0 and then i got 11111234 device and vendor
04:42:26 --- quit: NaNkeen (Ping timeout: 260 seconds)
04:48:48 <akasei> as you can see there are strange rolls 3 and 5 ;) it's right choose regarding to first table at https://wiki.osdev.org/PCI
04:48:49 <bslsk05> ​wiki.osdev.org: PCI - OSDev Wiki
04:49:36 --- quit: sortie (Quit: Leaving)
04:54:02 --- quit: m_t (Quit: Leaving)
05:03:32 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
05:03:40 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
05:05:46 --- quit: immibis (Ping timeout: 260 seconds)
05:18:07 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
05:24:21 <akasei> if a BAR0 register of VBE return 0x00000000 it could mean that i should use 0xE000000 as fixed place of Linear Frame Buffer ?
05:25:35 --- quit: jakogut (Remote host closed the connection)
05:26:11 <Mutabah> Don't think so...
05:26:17 <Mutabah> if it's in PCI, BAR0 should be valid
05:28:05 <akasei> ok, so i check if VGA exist (yes 00:02.0), change VBE resolution to 1280x720@32 and tried to read BAR0 from (00:02.0) it was empty
05:28:44 <akasei> or the could be another bug
05:28:45 <Mutabah> What address are you writing to 3F8?
05:28:51 <akasei> please tell me what means in C "(offset & 0xfc)"
05:28:53 <Mutabah> Check that against something manually calculated
05:29:25 <Mutabah> `&` is bitwise AND operation
05:30:19 <akasei> this is my prepared output for 0xCF8 > 0x80011310 for bus 1, device 2, function 3, register 0x04
05:30:24 <akasei> is it right?
05:30:59 <Mutabah> Function 3?
05:31:06 <akasei> this is example
05:31:25 <akasei> i only wanna know if my funcstion properly generated value
05:33:19 <akasei> this value 0x80001040 was generated for VGA (00:02.0)
05:33:26 <akasei> BAR0
05:35:19 <Mutabah> So, does that address look correct?
05:35:58 <akasei> i compared it to "Configuraton Space Access MEchanism #1" in https://wiki.osdev.org/PCI
05:36:02 <akasei> and is correct
05:36:16 <Mutabah> You sure?
05:40:01 <akasei> 1 enable 0000000 reserved 00000000 bus 00010 device 000 function 010000 register 00 zero
05:40:05 <akasei> yes
05:40:13 <akasei> oh
05:40:21 <akasei> register is suspicious ;)
05:40:25 <Mutabah> very
05:40:56 <akasei> thx for patience ;)
05:41:30 <Sjors> hi all!
05:41:33 <akasei> 010000 > 0x10 BAR0 register
05:41:41 <Sjors> I'm implementing ATA at the moment, reading about LBA
05:42:32 <Sjors> so I understand I have to use READ SECTORS EXT (0x24) to read from an ATA drive, and send the sectorcount in two bytes and LBA in 6 bytes over various parts (to a drive that supports LBA-48)
05:42:41 <Sjors> are sectors always 512 bytes?
05:42:56 <Sjors> and what is the difference in bytes between LBA address n and n+1? is it also always 512?
05:42:57 <akasei> no
05:43:41 <akasei> Mutabah: i think 010000b is good value for BAR0
05:43:52 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-ckasfyblfmflnkty) joined #osdev
05:53:14 <akasei> Mutabah: ok i found the problem
05:53:47 --- join: tacco| (~tacco@i59F4D3DB.versanet.de) joined #osdev
05:53:48 <akasei> and this is of misunderstood of table
05:54:05 <akasei> this example is wrong from my point of view
05:54:29 <akasei> it says that bits 7..2 should handle register offset
05:54:38 <akasei> and bits 1..0 are clean
05:54:50 <akasei> so i put BAR0 in 7..2
05:55:07 <akasei> but they should be in 7..0
05:55:23 <akasei> now its working
05:55:29 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
05:55:54 <akasei> this table at https://wiki.osdev.org/PCI wrong
05:55:54 --- quit: Oxyd76 (Read error: Connection reset by peer)
05:55:55 <bslsk05> ​wiki.osdev.org: PCI - OSDev Wiki
05:56:05 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
06:01:46 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
06:01:52 <Mutabah> which table?
06:02:05 <akasei> Configuration Space Access Mechanism #1
06:02:11 <Mutabah> eeehh...
06:02:21 <akasei> what?
06:02:24 <Mutabah> it says "register number" - distinct from "register offset"
06:03:02 <akasei> but why it must be so compicated? offset will be much simpler
06:04:00 <Mutabah> It's emphesising that value written must be a multiple of 4
06:05:13 <akasei> ok logical, but i will stay on my word ;)
06:05:43 --- join: S_Gautam (3bb6feb7@gateway/web/freenode/ip.59.182.254.183) joined #osdev
06:05:54 <Mutabah> It's the sad state of the wiki, there's a lot of correct but badly presented information there
06:06:36 <akasei> i admit,
06:07:22 <Sjors> for a particular drive, where would I found its amount of bytes per sector / bytes per block?
06:07:34 <Sjors> is that in the ATA identification?
06:08:03 <Mutabah> Sjors: yes, it's in the IDENTIFY block
06:08:03 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
06:08:05 <Mutabah> ... somewhere
06:08:43 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
06:08:56 <Sjors> is a sector the same as a block in this sense?
06:09:07 <Sjors> the wiki says: "uint16_t 100 through 103 taken as a uint64_t contain the total number of 48 bit addressable sectors on the drive. (Probably also proof that LBA48 is supported.)"
06:09:12 <Sjors> I would say that's 48-bit addressable blocks
06:09:23 <S_Gautam> tfw rarlab is the 8th or 9th Google result when you want to download WinRAR
06:09:29 <Mutabah> Sjors: Yes.
06:09:40 <Sjors> Mutabah: ah good, that clears up that
06:09:46 <Sjors> s/up that/that up/
06:09:49 --- quit: pie_ (Ping timeout: 240 seconds)
06:12:16 --- join: climjark_ (~climjark@c-24-0-220-123.hsd1.nj.comcast.net) joined #osdev
06:15:24 --- join: lldd_ (~atrapado@unaffiliated/atrapado) joined #osdev
06:16:13 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:18:36 --- quit: Oxyd76 (Client Quit)
06:29:30 --- join: glauxosdever (~alex@athedsl-110985.home.otenet.gr) joined #osdev
06:31:38 --- quit: Philpax (Ping timeout: 256 seconds)
06:32:43 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
06:41:03 <ALowther> I am interested in writing my first, lower level?, client. In this instance, I am looking at writing an RTSP client, but really I am looking to understand and have the ability to look at any standard protocol and be able to write a client/server for it....When I work with Node.js to write an HTTP Server, all of the "hard" stuff is conveniently abstracted away and I can just work with JSON. I want to understand how to start working with thing
06:41:03 <ALowther> s on those lower levels. If I am reading a protocol, what kind of object form does the data need to be in? Maybe objects don't exist on that low of a level...I am not really even sure what to ask, hopefully you can see through my inability to articulate well and maybe point me in the direction of some useful articles/readings? I've found some, but idk if there are some in particular that any of you found to be especially helpful....Thanks :)
06:41:03 <ALowther>
06:45:28 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:47:46 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
06:50:11 <baschdel> Depends on what kind of infrastructure you already have . If you want to make something like a simple http server look at the http protocol, figure out wht you need to get up to that layer (TCP,IP,networking,etc. and try to get everything working until you get some raw http and then work your way up the abstraction layers until you get the server)
06:50:48 <baschdel> At least that's how I would approach it
07:11:05 <ALowther> baschdel: Okay, makes sense. So I need to determine which layer the protocol works on, then figure out how to deal with the raw data coming from the layer beneath it.
07:11:07 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
07:11:26 --- join: jmill (~textual@2605:6000:1019:3ff:d4be:646a:13e5:4b9b) joined #osdev
07:12:00 <baschdel> Yes, And if these layers don't exist just make them ...
07:12:18 <baschdel> That's how I'm writing my whole OS
07:21:11 --- quit: zeus1 (Ping timeout: 248 seconds)
07:33:32 --- quit: jjuran (Read error: Connection reset by peer)
07:33:48 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
07:44:06 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
07:44:26 --- quit: freakazoid0223 (Ping timeout: 260 seconds)
07:53:35 --- quit: lachlan_s (Quit: Connection closed for inactivity)
07:56:28 --- join: Shikadi (~Shikadi@cpe-98-10-34-205.rochester.res.rr.com) joined #osdev
08:05:30 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:08:45 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:09:45 --- quit: variable (Quit: /dev/null is full)
08:19:47 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-fsftiusptjwdiyyj) joined #osdev
08:33:31 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
08:43:59 --- quit: climjark_ (Ping timeout: 256 seconds)
08:44:19 --- quit: aalm (Ping timeout: 240 seconds)
08:44:40 --- quit: JusticeEX (Ping timeout: 256 seconds)
08:45:11 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
08:49:14 --- join: aalm (~aalm@37-219-237-30.nat.bb.dnainternet.fi) joined #osdev
08:54:17 --- join: mipicdev (~mipicdev@p200300E4ABC24255D021D0B825E2BB33.dip0.t-ipconnect.de) joined #osdev
09:00:31 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:01:33 --- quit: awang (Ping timeout: 256 seconds)
09:05:52 --- join: climjark_ (~climjark@c-24-0-220-123.hsd1.nj.comcast.net) joined #osdev
09:06:40 --- quit: NaNkeen (Ping timeout: 268 seconds)
09:11:56 --- quit: zaquest (Ping timeout: 260 seconds)
09:14:01 <lachlan_s> Is there any harm in reading a larger size value from an io port?
09:14:23 <lachlan_s> Like, when you want a byte, is there any harm in reading a dword?
09:17:34 --- join: DeepIO (~DeepIO@dyndsl-085-016-235-166.ewe-ip-backbone.de) joined #osdev
09:18:48 <clever> lachlan_s: some hardware may perform an action upon read, and depending on the bus width, reading a dword may involve several smaller reads
09:20:17 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
09:29:21 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
09:31:09 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
09:31:23 --- quit: mipicdev (Ping timeout: 276 seconds)
09:34:41 --- quit: X-Scale (Ping timeout: 260 seconds)
09:35:00 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
09:35:56 --- quit: awang (Ping timeout: 276 seconds)
09:35:59 <variable> #ifndef ALL_STATE tmp->TM_ZONE = gmtptr->chars; #endif /* State Farm */
09:36:02 <variable> someone was having fun
09:36:12 <doug16k> lachlan_s, yes. don't do it. I/O ports aren't memory
09:36:26 <variable> lachlan_s: to add to clever's comments: some hardware may leave junk on the I/O port
09:36:39 <variable> don't read more than you asked for
09:36:58 <doug16k> lachlan_s, however, it depends on the device. often modern devices have strict requirements for size of I/O accesses
09:38:23 <doug16k> on a modern device you should be using memory mapped I/O, where the memory accesses must be the correct size
09:40:42 <doug16k> most devices document 8 or 16 bit accesses to be undefined behaviour. if you're lucky, the undefined read will read as zero
09:44:19 <variable> things I hate dealing with: leap seconds
09:44:24 <variable> things I am dealing with: leap seconds
09:44:36 <variable> seriously, someone remind me why I got into computers
09:46:17 <variable> int idays; /* unsigned would be so 2003 */
09:46:22 <variable> I like this code
09:49:35 <aalm> :E
09:52:35 <doug16k> variable, why are you dealing with leap seconds? what are you doing?
09:52:50 <variable> doug16k: trying to figure out why gmtime(3) is broken
09:53:21 <variable> doug16k: not all #osdev is hardware </joke>
09:56:56 <clever> i have also see an i2c device, where if you do a 16bit read of a given address, you get the data you expect
09:57:08 <clever> but if you do a pair of 8bit reads, at consecutive addresses, the 2nd one is all 0's
10:10:13 --- quit: variable (Quit: /dev/null is full)
10:10:27 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
10:10:31 --- quit: zerd (Read error: Connection reset by peer)
10:10:38 --- join: zerd (~quassel@bat.slash.no) joined #osdev
10:10:54 --- quit: epony (Quit: QUIT)
10:17:23 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
10:18:11 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
10:22:00 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:29:44 <doug16k> nice, found x86_64 abi spec dated 2018: https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-cet.pdf
10:30:59 <variable> lol
10:31:11 <doug16k> ?
10:33:26 <doug16k> what's funny? most of the copies of it you find on the internet are from years ago
10:33:43 --- quit: awang (Ping timeout: 264 seconds)
10:34:11 <variable> doug16k: that's what's funny
10:34:23 <variable> that you had to expend effort to find a recent version
10:34:42 <variable> it annoys me for example that every google result for POSIX gives ancient versions
10:35:08 <doug16k> exactly. and chapter 8 still says "Not done yet", :)
10:36:06 --- join: X-Scale (~ARM@83.223.235.236) joined #osdev
10:36:16 <variable> doug16k: also now that I think about, I find it amusing that you need a 64bit ABI for 16k of RAM
10:36:38 <variable> I may or may not ascribe undue importance to people's nicks
10:37:04 --- nick: doug16k -> doug64g
10:38:45 --- join: epony (~nym@79-100-134-61.ip.btc-net.bg) joined #osdev
10:39:48 --- nick: doug64g -> doug16k
10:41:08 --- quit: epony (Max SendQ exceeded)
10:41:27 --- join: hmmmm (~sdfgsf@pool-72-79-162-68.sctnpa.east.verizon.net) joined #osdev
10:41:27 --- join: epony (~nym@79-100-134-61.ip.btc-net.bg) joined #osdev
10:50:41 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:54:20 --- join: CRoemheld (584610f2@gateway/web/freenode/ip.88.70.16.242) joined #osdev
10:54:33 --- quit: vdamewood (Client Quit)
10:54:34 <CRoemheld> Hey there :)
10:55:27 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:55:34 <CRoemheld> Is there anyone around who can help me with a small assembler specific question?
10:55:36 --- join: hussein (~hussein@175.144.17.102) joined #osdev
10:56:15 <Shockk> don't ask to ask
10:57:53 <CRoemheld> Alright, I'm using the intel syntax in assembler, and most of the tutorials on OSDev user the AT&T syntax. The common instructions are simple to replace / rewrite to intel syntax, however, I have some labels with parameters and I don't know what the specific term for this is
10:58:02 <CRoemheld> E. g.:
10:58:17 --- quit: nur (Ping timeout: 268 seconds)
10:58:26 <CRoemheld> [GLOBAL isr%1]
10:58:38 <CRoemheld> for the different isr stubs
10:58:56 <CRoemheld> (Taken from http://www.jamesmolloy.co.uk/tutorial_html/4.-The%20GDT%20and%20IDT.html)
10:58:56 <bslsk05> ​www.jamesmolloy.co.uk: 4.-The GDT and IDT
10:59:40 <CRoemheld> What is the term for this kind of parameterization in labels and how do I rewrite this in the intel syntax?
10:59:44 --- join: lf94 (~lf94@mtrlpq4806w-lp140-03-76-64-242-104.dsl.bell.ca) joined #osdev
11:01:33 <lldd_> those seem already intel syntax
11:13:39 --- quit: m3nt4L (Remote host closed the connection)
11:16:43 <doug16k> CRoemheld, that is the macro syntax. the macro parameter replaces the %1 at each use of the macro
11:17:07 <doug16k> see the nasm documentation
11:17:48 <doug16k> and yes, it is already intel syntax
11:23:44 <drakonis> who was it that was making an shooty mans game engine
11:23:47 <drakonis> i forgot
11:26:23 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
11:27:21 --- quit: samirhali (*.net *.split)
11:27:23 --- quit: Ringil[m] (*.net *.split)
11:27:23 --- quit: greaser|q (*.net *.split)
11:27:23 --- quit: tux3 (*.net *.split)
11:30:26 --- quit: sham1 (*.net *.split)
11:30:26 --- quit: zopsi (*.net *.split)
11:30:26 --- quit: lucebac (*.net *.split)
11:30:26 --- quit: diginet (*.net *.split)
11:30:26 --- join: greaser|q (greaser@antihype.space) joined #osdev
11:30:26 --- join: diginet (~diginet@107.170.146.29) joined #osdev
11:30:26 --- join: tux3 (tux@cmdline.org) joined #osdev
11:30:26 --- join: zopsi_ (~zopsi@2607:5300:60:9f36::) joined #osdev
11:30:26 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
11:30:26 --- quit: lucebac (Changing host)
11:30:26 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
11:30:26 --- join: sham1 (~sham1@212.146.44.37) joined #osdev
11:30:26 --- quit: kataria[m] (*.net *.split)
11:30:26 --- quit: Drakonis[m] (*.net *.split)
11:30:26 --- quit: jsgrant[m] (*.net *.split)
11:30:26 --- quit: Lucretia (*.net *.split)
11:30:26 --- quit: ptx (*.net *.split)
11:30:26 --- quit: ^Inuyasha^ (*.net *.split)
11:30:26 --- quit: RudyValencia (*.net *.split)
11:30:26 --- quit: bluezinc (*.net *.split)
11:30:26 --- quit: merry (*.net *.split)
11:30:26 --- join: RudyValencia (rudy@unaffiliated/rudyvalencia) joined #osdev
11:30:26 --- join: ptx (~ptx@563400ad.rev.stofanet.dk) joined #osdev
11:30:26 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
11:30:26 --- quit: Lucretia (Changing host)
11:30:26 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
11:30:26 --- join: bluezinc (~bluezinc@unaffiliated/bluezinc) joined #osdev
11:30:26 --- join: merry (~mage@unaffiliated/merry) joined #osdev
11:30:26 --- join: ^Inuyasha^ (~quassel@vmi86808.contabo.host) joined #osdev
11:30:26 --- join: m_t (~m_t@p5DDA3191.dip0.t-ipconnect.de) joined #osdev
11:30:26 --- nick: zopsi_ -> zopsi
11:30:26 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
11:31:08 --- join: samirhali (~samirhali@80.211.230.116) joined #osdev
11:38:48 --- join: Ringil[m] (ringilmatr@gateway/shell/matrix.org/x-msaxqxommgcrkyxn) joined #osdev
11:39:55 --- join: Drakonis[m] (drakonisma@gateway/shell/matrix.org/x-kcapaghbdghtipdh) joined #osdev
11:42:34 --- join: jsgrant[m] (jsgrantmat@gateway/shell/matrix.org/x-dhctkmlvbmvssncr) joined #osdev
11:44:14 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
11:44:20 --- quit: jsgrant[m] (*.net *.split)
11:44:20 --- quit: Ringil[m] (*.net *.split)
11:44:20 --- quit: Goplat (*.net *.split)
11:44:20 --- quit: m_t (*.net *.split)
11:44:20 --- quit: tux3 (*.net *.split)
11:44:20 --- quit: dbittman_ (*.net *.split)
11:44:20 --- quit: jjuran (*.net *.split)
11:44:21 --- quit: hl (*.net *.split)
11:44:21 --- quit: dude12312414 (*.net *.split)
11:44:44 --- quit: kuldeep (*.net *.split)
11:44:44 --- quit: m712 (*.net *.split)
11:44:44 --- quit: hydraz (*.net *.split)
11:44:44 --- quit: mniip (*.net *.split)
11:44:44 --- quit: r3n (*.net *.split)
11:44:44 --- quit: cruxeternus (*.net *.split)
11:44:44 --- quit: brynet (*.net *.split)
11:44:44 --- quit: fristonio[m] (*.net *.split)
11:44:44 --- quit: Nokurn (*.net *.split)
11:44:44 --- quit: Guest21615 (*.net *.split)
11:44:44 --- quit: Vercas (*.net *.split)
11:44:44 --- quit: tj (*.net *.split)
11:44:44 --- join: m712 (~annoying@unaffiliated/thefam) joined #osdev
11:44:44 --- join: tux3 (~tux@cmdline.org) joined #osdev
11:44:44 --- join: Vercas (~Vercas@gateway/tor-sasl/vercas) joined #osdev
11:44:44 --- join: cruxeternus (~cruxetern@secspeed.com) joined #osdev
11:44:44 --- join: Nokurn (~Nokurn@71-95-52-160.dhcp.rvsd.ca.charter.com) joined #osdev
11:44:44 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
11:44:44 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
11:44:44 --- join: r3n (~c@kana.node.kitteninfra.net.nz) joined #osdev
11:44:44 --- join: kuldeep (~kuldeep@unaffiliated/kuldeepdhaka) joined #osdev
11:44:48 --- join: Guest21615 (~testerr@206.189.79.99) joined #osdev
11:44:57 --- join: hydraz (hydraz@coleridge.vehk.de) joined #osdev
11:44:57 --- quit: hydraz (Changing host)
11:44:57 --- join: hydraz (hydraz@unaffiliated/demhydraz) joined #osdev
11:44:59 --- join: tj (~tj@strlen.org) joined #osdev
11:45:06 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
11:45:16 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
11:45:26 --- join: dude12312414 (None@gateway/shell/elitebnc/x-drukiuvjvbexwges) joined #osdev
11:46:03 --- join: mniip (mniip@freenode/staff/mniip) joined #osdev
11:46:49 --- quit: freakazoid0223_ (Ping timeout: 240 seconds)
11:47:03 <CRoemheld> @doug16k It seems that it might actully be intel syntax, however when compiling it with my cross compiler, it gets me errors like "Error: junk at end of line, first unrecognized character is `%'"
11:47:30 <CRoemheld> I just found out that for intel syntax, the proper macro directive is .macro
11:47:41 --- quit: samirhali (Ping timeout: 260 seconds)
11:47:46 <CRoemheld> but I still don't know how to append parameters
11:48:43 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
11:49:13 --- join: samirhali (~samirhali@80.211.230.116) joined #osdev
11:49:16 --- join: fristonio[m] (fristoniom@gateway/shell/matrix.org/x-pzrrkelktmszcvbg) joined #osdev
11:49:27 <doug16k> CRoemheld, that code is nasm assembly code. you can't compile that with gcc
11:49:53 <doug16k> yes, gnu assembler has a completely different macro syntax
11:50:30 <doug16k> it's not a matter of intel syntax or not, it is a matter of which assembler you are using to compile the code
11:50:56 <CRoemheld> I am using my cross compiler, as used in the bare bones tutorials
11:51:01 --- join: grumblr (~grumble@freenode/staff/grumble) joined #osdev
11:51:04 --- join: kataria[m] (katariamat@gateway/shell/matrix.org/x-pxolkiiijccjjbwf) joined #osdev
11:51:13 --- quit: grumble (Quit: Just imagine, if we found aliens who have their own version of the internet, they'd probably have some hella dank memes to share.)
11:51:34 --- nick: grumblr -> grumble
11:51:34 <doug16k> CRoemheld, here is my code for doing an equivalent thing in gnu assembler syntax: https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/isr.S#L22
11:51:37 <bslsk05> ​github.com: dgos/isr.S at master · doug65536/dgos · GitHub
11:52:12 --- join: Ringil[m] (ringilmatr@gateway/shell/matrix.org/x-syxvqrhxwwanxkrb) joined #osdev
11:53:00 --- join: hl (m148833mat@gateway/shell/matrix.org/x-cmdstjtqtfkoeyxe) joined #osdev
11:53:22 <CRoemheld> @bslsk05: Thanks a lot! seems like the .macro and .endm were correct after all
11:53:41 --- join: jsgrant[m] (jsgrantmat@gateway/shell/matrix.org/x-ghwhhxogkembdhqf) joined #osdev
11:53:41 <doug16k> np
12:02:27 --- quit: DeepIO (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
12:02:38 --- join: DeepIO (~DeepIO@dyndsl-085-016-235-166.ewe-ip-backbone.de) joined #osdev
12:02:39 --- quit: DeepIO (Max SendQ exceeded)
12:02:43 --- join: daniele_athome (~daniele_a@5.170.129.190) joined #osdev
12:03:54 --- join: m_t (~m_t@p5DDA3191.dip0.t-ipconnect.de) joined #osdev
12:06:21 <S_Gautam> I like FASM's macro syntax, really simple and intuitive IMO.
12:06:40 <S_Gautam> macro fun arg1, arg2 { dd arg1 dd arg2 }
12:09:20 --- quit: S_Gautam (Quit: Page closed)
12:11:12 --- quit: variable (Quit: /dev/null is full)
12:13:48 --- quit: CRoemheld (Quit: Page closed)
12:23:55 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
12:26:40 --- quit: Vercas (*.net *.split)
12:26:49 --- join: Vercas (~Vercas@unaffiliated/vercas) joined #osdev
12:28:39 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
12:28:51 --- quit: trout (Client Quit)
12:32:57 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
12:33:49 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
12:38:11 --- quit: Mutabah (Ping timeout: 268 seconds)
12:38:19 --- join: Mutabah (~tpg@pdpc/supporter/student/thepowersgang) joined #osdev
12:38:24 --- quit: variable (Ping timeout: 252 seconds)
12:52:34 --- quit: drakonis (Remote host closed the connection)
12:54:33 --- quit: lldd_ (Quit: Leaving)
12:55:51 <lachlan_s> geist: In fuchsia, what are ports?
12:55:58 <lachlan_s> It's not clear if they're io ports or something else
12:56:11 --- quit: AverageJ0e (Ping timeout: 265 seconds)
13:00:48 --- join: bauen1 (~bauen1@ANancy-655-1-10-165.w86-223.abo.wanadoo.fr) joined #osdev
13:00:54 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:01:35 --- quit: variable (Client Quit)
13:04:59 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:06:31 --- quit: variable (Read error: Connection reset by peer)
13:07:10 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:08:14 --- quit: user10032 (Quit: Leaving)
13:09:51 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
13:10:03 --- quit: trout (Client Quit)
13:12:19 --- quit: variable (Ping timeout: 260 seconds)
13:15:42 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:20:15 --- quit: variable (Ping timeout: 260 seconds)
13:25:26 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:49:59 <geist> they are not io ports
13:58:40 --- quit: quc (Remote host closed the connection)
14:00:09 --- quit: zeus1 (Ping timeout: 245 seconds)
14:01:24 --- quit: bauen1 (Ping timeout: 245 seconds)
14:05:49 --- quit: oaken-source (Ping timeout: 240 seconds)
14:05:54 <lachlan_s> geist: how does a process interact with io ports on fuchsia? Normally, of course, it would map in mmio
14:06:26 --- quit: glauxosdever (Quit: leaving)
14:08:04 --- quit: daniele_athome (Ping timeout: 245 seconds)
14:08:10 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-jljwzpduvsafqwrb) joined #osdev
14:10:04 --- quit: Asu (Ping timeout: 256 seconds)
14:10:18 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:13:22 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
14:13:59 --- join: Asu (~sdelang@39.41.136.77.rev.sfr.net) joined #osdev
14:15:12 --- quit: variable (Ping timeout: 245 seconds)
14:16:33 --- join: hussein__ (~hussein@175.142.120.67) joined #osdev
14:18:51 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
14:18:57 --- quit: hussein (Ping timeout: 240 seconds)
14:29:35 --- join: jmill (~textual@2605:6000:1019:3ff:d4be:646a:13e5:4b9b) joined #osdev
14:30:31 <geist> lachlan_s: yes normally, and on anything but x86 mmio is a thing
14:30:46 <geist> there's a way to request access to a range of io ports per process
14:30:57 <geist> and the kernel tracks that and adjusts the io bitmap on context switch
14:31:19 --- part: akasei left #osdev
14:40:10 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
14:41:01 <lachlan_s> geist: the io bitmap?
14:41:36 <geist> the io bitmap. it's an x86 feature
14:42:00 <geist> basically you can grant per io port access for a ring3 process
14:43:05 --- join: zeus1 (~zeus@197.239.7.106) joined #osdev
14:44:29 <lachlan_s> Ah, interesting!
14:44:32 <lachlan_s> Didn't know that
14:45:01 <geist> yeah it's part of the TSS
14:45:12 <geist> it's annoying because that means you basically have to patch it on context switch
14:46:30 <Belxjander> so limited access to ioports based on access permissions ? ... driver asks for ports so it gets permissions and exclusive ownership of a hardware device ?
14:46:48 --- quit: xenos1984 (Quit: Leaving.)
14:47:28 <lachlan_s> geist: Is there a syscall for that on fuchsia?
14:47:35 --- quit: immibis (Ping timeout: 248 seconds)
14:47:47 <geist> sort of yes. it's part of the capability model
14:48:22 <geist> essentially there are priviledged enough handles that the bus driver processes can grant your process (a driver) io permissions
14:48:29 <geist> generally speaking the driver can't do it directly
14:49:12 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
14:51:50 --- join: Sonicbit (~Sonicbit@185.53.85.8) joined #osdev
14:53:43 --- join: vinleod (~vdamewood@unaffiliated/vdamewood) joined #osdev
14:53:52 <lachlan_s> geist: Does it manage mapped physical memory as well?
14:54:02 <lachlan_s> For instance, only one process can map in this range of memory?
14:54:02 <geist> yes but that's a different mechanism
14:54:09 <geist> correct
14:54:47 <lachlan_s> What method do you use to look that up?
14:54:58 <geist> look what up specifically?
14:54:58 <lachlan_s> Is it just an array of the mapped ranges, and you iterate through that to check?
14:55:39 <geist> well... it's complicated
14:55:55 --- quit: vdamewood (Ping timeout: 260 seconds)
14:55:57 <geist> it doesn't work that way actually. it's inverted from the model you're thinking of
14:56:06 <geist> the driver doesn't ask for a mmio range, io range, or bitmpa
14:56:21 <geist> it's *given* handles to objects that represent those ranges by the higher level bus manager
14:56:38 <geist> the bus mananger is either a process (legacy bits for PC for example that represents the PC 'bus')
14:56:49 <geist> or the PCI bus (which is currently in the kernel but will be moved out to a process)
14:57:10 <geist> those bus maangers have essentially the sole responsibility of carving up io/mmio/interrupt space and then vending handles to driver processes
14:57:28 <geist> this way driver processes dont intrinsically have any more rights than any other process. they can't arbitrarily map mmio or io space
14:57:53 <geist> so in that case the data structures that disallow multiple io ranges from overlapping are part of the bus managers in user space
14:58:13 <geist> but if it weren't a microkernel, they'd just be part of whatever driver layer resource manager would typically live in the kernel
14:58:15 --- quit: zeus1 (Ping timeout: 260 seconds)
14:58:51 <geist> so for PCI devices this is fairly simple: the pci bus manager iterates the tree, figures out what mappings are needed for a device via the BAR windows
14:58:57 --- join: quul (~weechat@unaffiliated/icetooth) joined #osdev
14:59:21 <geist> constructs handles to those ranges of physical ram, and then starts a driver instance (matching the PCI vid/did, or whatnot to a driver .so file)
14:59:34 <geist> and hands the driver handles to these apertures into io space
14:59:36 --- join: Nicola__ (5d2c530e@gateway/web/freenode/ip.93.44.83.14) joined #osdev
15:00:04 <geist> the only real thing that the driver needs to request back from the PCI bus driver is access to interrupts, since they need to generally be allocated dynamically
15:01:27 --- quit: Asu (Ping timeout: 248 seconds)
15:03:48 <lachlan_s> geist: So, the ranges of physical memory just end up as VMOs?
15:04:12 <geist> that's correct. there's a special subclass of VMOs that just represent a range of physical memory
15:04:18 <lachlan_s> And the interrupts are these? https://github.com/fuchsia-mirror/zircon/blob/master/docs/syscalls/interrupt_create.md
15:04:20 <bslsk05> ​github.com: zircon/interrupt_create.md at master · fuchsia-mirror/zircon · GitHub
15:04:27 <geist> they support less features: you can't clone them, you can't read/write them directly, you can really only map them
15:04:28 --- join: Asu (~sdelang@76.41.136.77.rev.sfr.net) joined #osdev
15:04:37 <geist> and they're usually vended out un-duplicatable and non-transferrable
15:04:41 <lachlan_s> Ah, I see
15:04:42 <geist> that way a driver process can't 'leak' it
15:04:51 <lachlan_s> Makes sense
15:04:58 <lachlan_s> Like a kernel borrowchker
15:05:02 <geist> yah the driver model basically assumes that drivers are bad actors
15:05:24 <geist> since in our experience, they are. we're trying to make sure drivers can't go add back doorsto the system and play within their little box properly
15:06:11 <geist> and yes thats the raw syscallfor interrupt create. note that a driver may not have access to that syscall, it is probably generally asking the bus layer it's attached to to create one on its behalf
15:06:23 <geist> that way the bus driver can account for things properly. Especially for more dynamic interrupts like MSI
15:06:29 <lachlan_s> And it hands over the handle to it?
15:06:33 <geist> correct
15:06:46 <lachlan_s> So, the handle back to the bus manager is sent over in the process init channel?
15:06:59 <geist> for more fixed things like builtin devices you find on a random arm SoC, there's probably a per soc 'bus' process that just direct creates these things
15:07:27 <geist> yes, or is mapped into the device's / space so it can find it
15:07:45 <geist> that's getting plumbed out more officially now as most of the system switches over to the full FIDL IPC model
15:08:13 <geist> since the drivers/devmgr/etc came up first while developing the system, we tended to slam together one off bespoke solutions for the driver api ipc
15:08:21 <geist> and are now refactoring it to look like everything else
15:08:32 --- nick: vinleod -> vdamewood
15:08:57 <geist> wehat's amazing is watching all this work. it starts up in like 100ms, all these processes are just starting up and negotiating all this stuff in zero time
15:10:04 <geist> generally speaking the system is up and all the driver processes are up and running in less than 500ms on an intel box
15:11:18 --- quit: Kimundi_ (Remote host closed the connection)
15:11:29 --- join: Kimundi_ (~Kimundi@i577A91E4.versanet.de) joined #osdev
15:13:23 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
15:14:15 --- quit: variable (Client Quit)
15:15:13 <lachlan_s> geist: Just looked up fidl
15:15:15 <lachlan_s> Very cool
15:16:00 <geist> yeah it's under active development, but we're going back and plumbing out all the layers properly with it
15:20:07 <lachlan_s> What are the interfaces in fidl?
15:20:11 <lachlan_s> Are they like rpc?
15:20:34 <geist> yep
15:20:44 <geist> it builds the code to encapsulate the ipc
15:21:01 <geist> in multiple languages too, so you can interop between them
15:21:56 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
15:22:10 --- quit: Nicola__ (Quit: Page closed)
15:22:34 <lachlan_s> Does it verify that the format is the same?
15:22:44 <lachlan_s> Or just hope that both ends have the same fidl file?
15:23:00 <geist> i honestly dont know, there should be some docs on it in there somewhere
15:23:27 <geist> well, my little hifive1 board came in
15:23:40 <geist> it's a lot smaller than i expected
15:23:59 <lachlan_s> This is really cool stuff
15:24:23 <geist> lachlan_s: hav eyou ever tried building and running zircon? it should be pretty easy
15:24:32 <lachlan_s> I haven't no
15:24:37 <lachlan_s> I'll do it at some point
15:24:48 <lachlan_s> Spending most of my free time working on nebulet
15:24:52 <geist> somewhat more involved to build the entire fuchsia stack, but just zircon is pretty easy to check out and build, assuming you're using a debian like linux distro and/or a mac
15:25:00 <geist> since there are some prebuitls involved
15:25:22 <Belxjander> I wonder if that would work on an RPi board with the ARM SoC on that
15:27:06 <geist> two pronouns in a single sentence, double jeopardy figuring out what the sentence means
15:27:38 <Belxjander> eh?
15:27:51 <geist> what would work on what?
15:27:53 * Belxjander has only just gotten home from night shift
15:28:15 <Belxjander> I was wondering if zircon/fuchsia would work on an RPi's ARM processor
15:28:20 --- quit: brynet (Quit: leaving)
15:28:24 <Belxjander> or possibly a PowerPC processor
15:28:28 --- quit: m_t (Quit: Leaving)
15:28:31 <geist> it did. on a rpi3. we just finally dropped support for the board
15:28:44 <lachlan_s> geist: Does fidl have any kernel support (for transferring handles, etc), or is it all just implemented on top of channels?
15:28:46 <geist> powerpc we'd have to port, but we only really support 64bit arches, so it'd have to be a ppc64
15:28:46 <Belxjander> or would it be limited to x86-32 or x86-64 architecture at this time?
15:29:03 <geist> lachlan_s: on top of channels. the kernel never ever parses any ipc. it only moves bits fro A to B
15:29:09 <geist> Belxjander: arm64 as well
15:29:14 <Belxjander> ahhh
15:29:18 <geist> at the moment we specifically target x86-64 and arm64
15:29:18 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
15:29:22 <Belxjander> then I can't use it at all
15:29:34 <geist> we made a fairly concious effort to drop 32bit and focus on 64bit across the board
15:29:35 <Belxjander> as I would be wanting a 32bit restricted target setup
15:29:47 * geist nods
15:30:27 <Belxjander> I'm currently looking at what I can use as a kernel layer inside a container virtualisation system I've written
15:31:15 <lachlan_s> geist: Channels have a buffer in the kernel, right?
15:31:16 <Belxjander> basically I want to pre-fill the containers with an existing micro-kernel to load shims into the container with and keep Applications which are contained isolated off the host system as much as possible without actually looking like I am doing that
15:31:37 <geist> that's correct
15:31:59 --- quit: Asu (Quit: Konversation terminated!)
15:36:19 --- quit: climjark_ (Ping timeout: 240 seconds)
15:37:49 --- quit: Love4Boobies (Remote host closed the connection)
15:40:10 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
15:44:40 <lachlan_s> I suppose I'll need something like that for nebulet at some point
15:45:47 <lachlan_s> I could actually have modules do rpc by calling exported functions from another module, but since you couldn't actually send a buffer over, I think it'd be more trouble than it would be worth
15:46:16 --- quit: awang (Ping timeout: 260 seconds)
15:56:41 --- quit: light2yellow (Quit: light2yellow)
15:58:02 <mischief> geist: mips64 when
15:58:03 --- quit: baschdel (Ping timeout: 256 seconds)
15:58:55 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
16:01:37 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:02:14 --- quit: spare (Ping timeout: 245 seconds)
16:04:43 <geist> mischief: sure, would need to get ahold of one though
16:05:11 <geist> they'r enot exactly flying off the shelves
16:06:14 <mischief> geist: my ERL is mips64
16:07:37 --- join: jmill (~textual@2605:6000:1019:3ff:d4be:646a:13e5:4b9b) joined #osdev
16:09:19 --- quit: Kimundi_ (Ping timeout: 240 seconds)
16:13:34 <lachlan_s> geist: is there really nothing like fidl that wouldn't have required writing fidl?
16:21:42 --- quit: Shamar (Quit: Lost terminal)
16:24:26 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:36:26 --- quit: CheckDavid (Quit: Connection closed for inactivity)
16:37:00 <geist> i dunno, honestly i'm not involved in those high level decisions
16:37:30 <geist> but as you can tell most of the fuchsia project is nt about reusing existing things, so any given component it's a bit hard to make a strong argument for 'but there's already something that does X'
16:38:56 <geist> i assume a fair amount of that is build exactly what you want and need and not reuse something that does mosty what you want
16:45:18 --- quit: sortie (Quit: Leaving)
16:45:31 --- join: troy16bit (~troy@2605:e000:7c8a:7200:dc62:fc9a:29c4:c514) joined #osdev
16:51:27 --- nick: troy16bit -> neh0x_
16:52:06 --- join: dhill0n (~dhillon@cpc112611-nrte30-2-0-cust187.8-4.cable.virginm.net) joined #osdev
16:52:12 <dhill0n> hehey
16:52:34 <dhill0n> anyone wanna smash (or trade kernel source files)?
16:53:04 <dhill0n> lmao but in all seriousness, is this related to osdev.org
16:53:22 <neh0x_> yes, it is.
16:53:28 <dhill0n> ok cool
16:54:03 * mischief smashes dhill0n
16:54:09 <dhill0n> do vb oses count
16:54:14 <dhill0n> if i use cosmos
16:54:34 <dhill0n> thanks for the smash btw mischeif
16:54:38 <dhill0n> it was gud
16:54:40 <dhill0n> )))
16:54:51 <mischief> i'm compiling python over nfs on a 500mhz mips64 cpu
16:54:54 <mischief> fight me.
16:55:14 <neh0x_> O_o
16:55:17 <dhill0n> damn that shit turns me on
16:55:47 <dhill0n> sounds dope though
16:55:58 <dhill0n> why 500 mhz mips64?
16:56:23 <neh0x_> how about, compiling darwin on an i386 DX ;-)
16:56:25 <mischief> this is an edgerouter lite
16:56:39 <exezin> Could someone explain why all documents detailing PAE only specify 3-levels and dont mention "PML4"?
16:56:43 <geist> mischief: hmm? what is ERL?
16:56:51 <mischief> geist: edgerouter lite
16:56:54 <geist> exezin: because PAE is 3 level paging
16:56:56 <mischief> https://www.ubnt.com/edgemax/edgerouter-lite/
16:56:58 <bslsk05> ​www.ubnt.com: Ubiquiti Networks - EdgeRouter™ Lite
16:56:58 <geist> ah
16:57:04 <exezin> geist: What would PML4 be then?
16:57:17 <geist> that is used in 64bit paging
16:57:30 <geist> which you can consider to be an extension to PAE i suppose, but isn't really PAE per se
16:57:47 <exezin> confusing because even the wiki says 64bit paging is 'PAE' :p
16:57:56 <neh0x_> Page Map Level 4. It's the way AMD decided to label their pagiging tables
16:57:57 <geist> well wikis are not perfect
16:58:05 <neh0x_> paging*
16:58:09 <exezin> neh0x_: intel adapted it right, just under a different name?
16:58:14 <neh0x_> yeah
16:58:16 <exezin> there's still 4-levels on modern systems
16:58:17 <geist> but yes, depending on your point of view 4 level (or 5 level paging) in 64bit land is PAE + more levels
16:58:23 <exezin> I'm trying to understand how it functions to be honest
16:58:24 <geist> and that's not entirely wrong. the manual may not specifically say that
16:58:28 <CompanionCube> isn't COSMOS a .NET thing, not specifically VB?
16:58:32 <geist> but, this is the fun of dealing with multiple sources of 'truth'
16:58:41 <exezin> tell me about it
16:58:44 <exezin> I have about 50 tabs open
16:58:45 <dhill0n> I was joking CompanionCube lmao
16:58:51 <dhill0n> But yes, its .NET I think :p
16:58:53 <exezin> everyone calls it something different which is always fun ;-;
16:59:01 <geist> when in doubt, the intel manual is truth, AMD is a second close truth
16:59:15 --- nick: dhill0n -> tr1nity
16:59:22 <neh0x_> geist LOL!!!
16:59:25 <exezin> so with generic 3-level PAE, CR3 points to the page directory
16:59:29 <geist> wikis and whatnot are generally just regurgiations of what people understand in presumably a friendlier way
16:59:33 <geist> but bit errors sneak in
16:59:41 <tr1nity> what is pae
16:59:47 <exezin> and in 4-level PAE, its still pointing at the page directory?
16:59:57 <lachlan_s> Physical address extension
16:59:59 <exezin> how does it translate a 4-level address on its own, is what im trying to comprehend
17:00:02 <geist> in 2-5 level paging, CR3 always points at the 'root'
17:00:11 <exezin> https://os.phil-opp.com/entering-longmode/X86_Paging_64bit.svg
17:00:17 <exezin> here CR3 points to PML4
17:00:20 <tr1nity> i see, thanks lachlan
17:00:21 <geist> that has never changed. it points at the root of the page tree
17:00:26 <exezin> I see
17:00:27 <neh0x_> tr1n1ty it allows operating systems to use more than 4GB of memory on x86 processors
17:00:31 <exezin> that actually helps a lot geist, thanks
17:00:35 --- quit: atk (Quit: Well this is unexpected.)
17:00:45 <exezin> I guess there are some hardware flags that indicate how many levels it has or something?
17:00:48 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
17:01:01 <exezin> (ie, how does it know to translate it as a 4-level address and not a 3-level one)
17:01:05 <geist> it's a combination of what mode you're in the PAE bit, and the new 5 level bit (i forget what it's called)
17:01:11 <tr1nity> neh0x_ youre an int pointer ;)
17:01:30 <tr1nity> ill shift ur bits <3
17:01:30 <geist> CR4.VA57 according to sandpile.org
17:01:57 <geist> in the case of x86-64 it simply is always 4 (or 5) level once you go to long mode
17:02:05 <geist> in x86-32 mode it's either 2 or 3 based on the PAE bit being set
17:02:16 <geist> and yes there are cpuid fields that tell you if the feature is present
17:02:23 <exezin> or 5?
17:02:28 <exezin> is that a thing hardware enforces?
17:02:42 <geist> it's a new thing coming along in intel cpus. it just adds another level
17:02:58 <exezin> I see, and I guess we'll be forced to use it in x86-64/long mode
17:03:04 <geist> does't really chance much except when you set it you now have another level
17:03:05 <exezin> (rather than the 4 we currently use)
17:03:06 <geist> correct
17:03:09 <exezin> oh boy
17:03:11 <geist> not forced, it's a bit you can enable
17:03:15 <exezin> ooh I see
17:03:21 <geist> hence the CR4.VA57 bit i was talking about
17:03:41 <exezin> so x86_64/long mode = 4 levels, and with 5-level hardware it can be enabled by a flag (otherwise defaults to 4 I imagine)
17:03:55 <geist> correct
17:04:05 <exezin> I should have come here earlire lol
17:04:08 <exezin> thanks
17:04:11 <geist> sure thing
17:05:03 <geist> http://sandpile.org/x86/crx.htm may be helpful too
17:05:04 <bslsk05> ​sandpile.org: sandpile.org -- x86 architecture -- control registers
17:05:17 <geist> really a lot of sandpile.org is good. i've never seen it have a mistake, it's high quality
17:05:26 <exezin> dope, thanks
17:05:27 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
17:06:50 --- join: [X-Scale] (~ARM@83.223.243.82) joined #osdev
17:08:26 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:09:34 --- quit: X-Scale (Ping timeout: 256 seconds)
17:09:34 --- nick: [X-Scale] -> X-Scale
17:14:08 --- quit: neh0x_ (Quit: Leaving)
17:17:33 --- quit: rain1 (Quit: Leaving)
17:17:39 --- quit: mra90 (Read error: Connection reset by peer)
17:21:49 --- quit: drakonis (Ping timeout: 245 seconds)
17:23:48 --- join: gwoplock (~quassel@cpe-76-183-186-15.tx.res.rr.com) joined #osdev
17:29:27 --- quit: `Guest00000 (Ping timeout: 240 seconds)
17:31:19 --- quit: tr1nity (Quit: WeeChat 2.2-dev)
17:37:33 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
17:48:08 <lachlan_s> geist: You have to read the entire message from a channel?
18:00:41 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
18:00:49 --- nick: promach__ -> promach2
18:01:52 <doug16k> qemu emulates la57 too, so you don't need the latest intel cpu to test/implement it
18:16:16 <doug16k> funny thing about la57 though, is that the architectural limit on physical addresses is currently 52 bits, so with la57 you end up with 32 times more linear address space than physical address space
18:17:02 <doug16k> la57 is good for extremely large extremely sparse mappings though
18:35:46 --- quit: promach2 (Quit: WeeChat 2.1)
18:44:43 <lkurusa> Good day #osdev
18:44:49 <lkurusa> actually it's most likely an evening
18:48:16 --- join: dengke (~dengke@60.247.85.82) joined #osdev
18:48:56 <klange> it's 11am-ish here
18:50:18 --- quit: Arcaelyx (Ping timeout: 276 seconds)
18:51:25 <lkurusa> 02:50 am here
18:51:38 <lkurusa> I can't sleep, so I'm spending some time on Spacemacs
18:56:32 <geist> lachlan_s: yes
18:56:44 <geist> you must read the entire message from a channel at once
18:57:33 <lachlan_s> So, you do `channel_read` with a len of 0 to find the size of the message, and then allocate a buffer of that size and try again?
18:58:02 <geist> you can do that, but in general you should know what sort of messages you're getting
18:58:14 <geist> and allocate buffers accordingly
18:58:32 <geist> note there's a max size message, i believe 64k, so worse case you allocate a buffer that large
18:59:48 <geist> also note that upon successful read you will have a new set of handles that were attached
18:59:57 <geist> you cannot not receive the handles
19:00:13 <geist> but of course you're free to close all the handles, and closing a handle can never fail
19:00:26 <lachlan_s> Ah, I see
19:01:16 <geist> the fact that handles are attached is part of what makes the channel api a little strict. its far more complicated (and thus slow) to allow reading the message in pieces, or rewind or whatnot
19:01:29 <geist> since the handle transfer also comes with it and cannot be done multiple times
19:01:37 <lachlan_s> Yeah
19:02:00 <geist> so by restricting it to precisely one read that either completely succeeds or completely fails simplifies the design substantially
19:03:11 <lachlan_s> I remembered you mentioning that fuchsia has a single table of kernel objects
19:03:18 <lachlan_s> How does it deal with contention on that?
19:03:47 <geist> not incredibly well
19:04:08 <geist> but i think a little bit of work we can at least remove the lock on lookup, just have to be clever with an atomic and some barriers
19:04:43 <geist> there are some nice advantages to having a single table though, mostly simplicity and efficiency of handle transfer (via channels) since there's no copying and it's far easier to roll back a bad transaction
19:04:57 --- quit: tacco| ()
19:05:30 <geist> right now though we do grab a single mutex to test when doing a handle lookup, which we should be able to remove, since forst the most part the mutex is only protecting the 'how big is the table' variable to validate that the handle is there
19:05:36 <geist> handle is within range that is
19:05:39 * variable grabs geist
19:05:50 * geist teehees
19:05:58 <lachlan_s> You could use a rwlock, I feel
19:06:05 <geist> no should be able to do it lockless
19:06:13 <geist> it's grabbing the lock in the first place that's the contention
19:06:38 <lachlan_s> How would it handle multiple threads/processes modifying the same object at the same time?
19:06:40 <geist> *should* be able to check that the handle is within the current size of the table (which can grow over time) via testing against an atomic
19:06:57 <geist> that's already handled with a ref ptr that the handle holds to the object
19:07:17 <lachlan_s> I thought that was just atomic reference counting
19:07:31 <geist> basically you look up the handle, validate that it's yours (the handle has a process id in it) and then bump the refptr on it
19:07:39 <lachlan_s> Yep
19:07:45 <geist> er refptr on the object it points to, now you have a ref to the object and you're fine
19:07:53 <lachlan_s> But that doesn't protect against concurrent accesses, right?
19:08:04 <lachlan_s> or writes
19:08:07 <geist> that's not the handle's problem
19:08:20 <geist> once you have a ref to the object, the object needs to provide whatever locking it wants to protect itself
19:08:27 <lachlan_s> Huh, I see
19:08:40 <lachlan_s> Actually, that makes a lot of sense
19:08:45 <geist> the handle just gets you from ID -> object in a ref safe way. now it's a different layer
19:09:13 <lachlan_s> I see
19:09:23 <lachlan_s> And the table is just a giant heap allocated sparse array?
19:09:33 <geist> also means if you destroy a handle while other threads are fiddling with the same object via the same handle you are racy intrinsically. the syscall layer makes no guarantees which order they appear in
19:10:03 <geist> it's perfectly fine to start an operation in a syscall on a handle and then simultaneously close it. it just depends on which 'phase' of the syscall it was in
19:10:16 <geist> if you caught it before it did the lookup or after
19:10:42 <geist> the table is a giant run of virtual address space in the kernel with a max size that gets bumped out as new handles are added
19:10:47 <geist> free handles are added to a free list
19:11:09 <lachlan_s> The free handle list is just a list of free indexes?
19:11:22 <geist> i forget. i think it's the handles itself in a list
19:11:46 <geist> iirc there's a double linked list pointer in it, either to hold it when its free or to hold it when it's attached to a process (for process iteration purposes)
19:12:12 <variable> you know what's really fun: fixing an 18 year old
19:12:13 <variable> bug
19:12:19 <variable> by deteting code
19:12:26 <variable> you know what's really fun: fixing an 18 year old bug by deleting code
19:12:28 <geist> oooh yes that's always a nice dopamine hit
19:12:49 <variable> to clarify: I did not remove the application; I actually fixed the bug
19:12:51 <geist> i did get my riscv machine yesterday, should try to bring up LK on it
19:13:05 <geist> was just reading the SoC manual. it's darn simple
19:13:09 <lkurusa> yay early bring up is the most fun
19:13:20 <lkurusa> i booted a simple kernel on my hifive 1
19:13:20 <geist> and yes, you're apparently supposed to run your code out of SPI flash + some amount of Icache
19:13:38 <lachlan_s> Thanks geist
19:13:40 <geist> which seems highly troublesome performance wise
19:13:48 <geist> lachlan_s: no problem. duck debugging is always good
19:14:00 <geist> having to describe something to folks helps you solidify it in your brain
19:14:13 <geist> though that's a bit higher up in the kernel than i usually mess with. I'm more of a Deep Kernel person
19:14:20 <geist> ie, what was formerly LK in zircon
19:14:36 <geist> vs the zircon executive which is essentially a layer on top of the LK kernel
19:14:46 <variable> I think freebsd supports riscv
19:14:57 <variable> I should actually try it out some time
19:15:00 <geist> variable: trouble with this board is it's basically a microcontroller class
19:15:06 <drakonis> according to mjg it doesn't even build
19:15:07 <geist> but, qemu also seems to have riscv stuff
19:15:16 <drakonis> qemu's riscv stuff is recent
19:15:26 <geist> yes. you need to be fairly near tip
19:15:44 <geist> same with gcc. you need to be building a pretty recent gcc to get support
19:15:55 <geist> i have no idea if clang/llvm is getting or has gotten riscv
19:15:56 <variable> what about clang?
19:15:58 <variable> drakonis: :(
19:16:29 <drakonis> clang hasn't upstreamed it yet
19:16:34 <geist> i'm sure someone is working on it
19:16:35 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:16:38 <_mjg_> the in-tree code does not build
19:16:44 <_mjg_> it used to boot sometime last year
19:16:50 <drakonis> wonder what happened
19:17:01 <variable> _mjg_: does anyone support it?
19:17:02 <drakonis> code dump?
19:17:10 <_mjg_> ask the people who committed it
19:17:18 <_mjg_> i have not seen them around for quite some time
19:17:44 <geist> i'm not completely enamored with the architecture, but it certainly doesn't offend me
19:19:21 <drakonis> qemu 2.12 has received qemu emulation code at least
19:19:30 <drakonis> the risc-v foundation's emulators have gone up
19:19:49 <drakonis> spike that is
19:20:46 <_mjg_> that's what fbsd boots on afair
19:22:31 <lachlan_s> Oh, hey geist, what does "fbl" stand for?
19:22:49 <drakonis> hm, surprising
19:23:39 <drakonis> https://www.sifive.com/blog/2018/04/25/risc-v-qemu-part-2-the-risc-v-qemu-port-is-upstream/ neat.
19:23:40 <bslsk05> ​www.sifive.com: RISC-V QEMU Part 2: The RISC-V QEMU port is upstream | SiFive
19:23:59 <drakonis> it does SiFive hardware
19:24:57 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
19:29:20 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:5147:9ab1:849:11ba) joined #osdev
19:29:31 <klange> I need a RISC-V machine with a display, I would so totally port to it.
19:31:39 <drakonis> this is fun
19:33:37 <geist> lachlan_s: fuchsia base library i think
19:34:48 <geist> so here's what i wonder: how does one generically determine which cores share the same LLC (last level cache)
19:35:12 <geist> i suspect it's at least intel and amd specific, but i dont see precisely in the cpuid where you can exactly figure it out
19:35:42 <geist> aside from of course just generally knowing
19:38:57 <geist> looking at the extra cpu cache stuff out of cpuid, you eventually do get a field for 'extra cores sharing this cache' on AMD or 'extra threads sharing this cache'
19:39:31 <geist> so i suppose wit a little bit of intel/amd specific knowledge you can piece together who belongs to the same LLC
19:40:26 <drakonis> oh yeah, interesting news it seems
19:40:43 <drakonis> sony is upstreaming large amounts of zen compiler code for llvm
19:40:51 <drakonis> looks like that's what'll run their ps5
19:40:56 <geist> makes sense
19:41:23 <geist> would be interesting to see what they'd actually be providing. is it additional tweaks above and beyond what is tere, or support for some vector extensions or whatnot
19:41:37 <drakonis> i wonder if it'll still be fbsd under the hood there
19:41:47 <drakonis> probably yes given their history but still
19:43:18 <drakonis> the zen code by sony isn't significnt yet
19:44:16 <geist> right may just be a new triple or whatnot
19:44:27 <geist> would be interesting to see if there are any hard core scheduling tweaks
19:45:35 <drakonis> nothing worth observing, sadly
19:46:09 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:46:47 --- quit: ALowther (Remote host closed the connection)
19:46:47 <geist> so it's more interestign in that they're submitting it, thus proving they're using zen
19:47:03 <drakonis> that's the main interesting thing
19:47:44 <drakonis> the only thing i do find weird is no "surprise MOFOS WE GOT PRESENTS FOR YA" code drops for freebsd like when they dropped AVX support
19:49:31 <drakonis> they're likely using vega or navi
19:49:55 <drakonis> which may cause an severe spike in hardware requirements for games
19:50:14 <drakonis> boy i can't wait to buy new hardware just so i can run things on acceptable rates
19:50:20 <geist> i am still constantly amazed at how great some PS4 games can look if you have a fixed hardware to optimize for
19:50:32 <geist> since theoretically the actual hardware is fairly so-so by PC standards nowadays
19:50:43 <drakonis> its like they say about programming, constraints are art
19:50:59 <drakonis> the hardware is really bad by today's standards
19:51:04 <drakonis> it was already dated when the ps4 released
19:51:15 <geist> exactly, a high end APU
19:51:24 <drakonis> it wasn't high end either to be honest
19:51:34 <drakonis> more like a middle end APU
19:51:38 <geist> certainly not the jaguar core
19:52:09 <geist> incidentailly i looked around the other day tos ee if i could find any sort of embedded bobcat/jaguar/family 16h machine to buy
19:52:18 <geist> but aside from PS4 they're unobtanium
19:52:29 <drakonis> hehehehe
19:52:34 <drakonis> well, you can buy a ps4 and mod it
19:52:51 <drakonis> so you can fiddle with the custom jaguar without the ps4 being in the way
19:53:06 <geist> that would probably be not a good idea
19:53:13 <variable> TIL about %n$ in printf in C
19:53:14 <geist> oh well, same goes for the via 64bit
19:54:34 <drakonis> checking consoles makes me think about game jams
19:54:47 <drakonis> esp the fantasy console jams due to limited resources
19:54:53 <geist> for lulz i hooked up my old xbox classic the other day and played through the start of Halo again
19:55:00 <drakonis> a good choice
19:55:02 <geist> even have the original The Duke controllers
19:55:13 <drakonis> why is it called "the duke"?
19:55:13 <variable> I'm in middle of playing through a bunch of modern games
19:55:17 <variable> like
19:55:20 <drakonis> modern games? bah humbug
19:55:21 <variable> Ocarina of Time
19:55:28 <geist> God of War I've been very happy with
19:55:34 <drakonis> wait, ocarina of time is modern???
19:55:35 <drakonis> say what
19:55:38 <variable> and Icewind Dale
19:55:42 <_mjg_> ha, curious if they are going to stick to bsd for ps
19:55:55 <klange> variable: $? I know %n is "write offset to pointer" (or do you mean putting it at the end of the string...)
19:56:02 <geist> now that anyone can write an os, why start with freebsd!
19:56:12 <variable> klange: no, its "use the Nth argument"
19:56:32 <variable> http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
19:56:33 <drakonis> have you tried gemrb before
19:56:34 <klange> oh %{n}$ that's very different from %n$ ;)
19:56:34 <bslsk05> ​pubs.opengroup.org: fprintf
19:56:44 <_mjg_> i'm yet to see use for %n other than format string exploitation
19:56:48 <variable> klange: yaya
19:56:59 <geist> and yeah i dunno why it's called The Duke
19:57:00 <drakonis> geist, legacy software my man
19:57:03 <geist> it is gigantic
19:57:05 <variable> drakonis: yes I have
19:57:11 <variable> drakonis: I even contributed to gemrb
19:57:18 <drakonis> a good choice
19:57:33 <drakonis> i gotta ask, can i pile up my massive amounts of terrible terrible baldur's gate 2 mods
19:57:34 <drakonis> ie
19:57:44 <variable> duno
19:57:46 <drakonis> what was that horrible mod with the paladin
19:57:53 <geist> part of it si probably because you also put the memory card in the controller back in xobxo classic
19:57:56 <drakonis> it was really poorly written
19:57:56 <klange> there's a lot of crazy stuff in the full specification for printf
19:57:56 <variable> drakonis: those are modern games for me btw
19:58:02 <drakonis> huh
19:58:02 <geist> which is one of those why the heck things, dreamcast had it too
19:58:05 <drakonis> how old are you now
19:58:10 <variable> 27
19:58:13 <geist> with the little random screen too that you could play tamagotchi on
19:58:15 <drakonis> wow you're older than me
19:58:30 <variable> how old are you?
19:58:32 <geist> oh if you're gonna play those at least play through Planescape: Torment
19:58:49 <variable> geist: already did
19:58:58 <drakonis> 25
19:59:12 --- quit: JusticeEX (Ping timeout: 276 seconds)
19:59:12 <variable> drakonis: same order of magnitude
19:59:17 <variable> so we're close enough
19:59:24 <drakonis> planescape torment is the best thing by chris avellone before he became a hack
19:59:33 <variable> "became a hack" ?
19:59:39 <drakonis> sorry
19:59:45 <drakonis> that one happens many years later
19:59:53 <variable> I know nothiing about people
19:59:55 <drakonis> he nuked his career a while ago
20:00:07 <variable> how?
20:00:28 <variable> waaait a moment
20:00:29 <variable> Baldur's Gate III: The Black Hound
20:00:31 <drakonis> yes
20:00:33 <variable> how did I not know there isa III ?
20:00:38 <drakonis> because it got cancelled
20:00:39 <variable> oh
20:01:02 <variable> drakonis: so, what happened to his career ?
20:01:17 <drakonis> he went to run his mouth about obsidian in the shittiest forum about rpgs, rpg codex
20:01:53 <drakonis> there's a thing called, what was it? "drinking your own kool aid"
20:02:11 <geist> yeah like many i was unable to get into the new torment thing
20:02:13 <drakonis> he was always "woah i'm so good man" now he's actually believing it
20:02:22 <geist> maybe it opens up after a while, but wow it's pretty rough getting started
20:02:25 <drakonis> its why the new torment was terrible despite him being on the helm
20:02:28 <variable> o
20:02:37 <drakonis> he's not very good
20:02:41 <variable> :(
20:02:51 <variable> was he good?
20:02:59 <drakonis> his early work? yes
20:03:02 <variable> the first games on that list are amazing
20:03:03 <drakonis> his recent work isn't
20:03:09 <variable> what made him go off the kilter?
20:03:21 <drakonis> ego
20:03:28 <variable> :(
20:03:39 <drakonis> i know it sucks
20:03:45 <drakonis> but at least his good games will stay good
20:04:06 --- join: NaNkeen (~nankeen@123.136.106.79) joined #osdev
20:04:27 <variable> drakonis: what are you talking about? The old games will eventually become older, and bitrot
20:04:35 <drakonis> not if i can stop it!
20:04:35 <variable> and we all know that rotten code can never be good
20:04:52 <variable> its like vegetables: the older code gets, the worse it is
20:05:16 <drakonis> wow ew
20:05:33 <variable> drakonis: what?
20:05:42 <drakonis> apparently the duke controller name was due to a ms injoke
20:05:48 <variable> oh
20:05:57 <variable> I thought that was a reaction to my well reasoned comments about code
20:05:58 <geist> i'm actually watching a random vid where the xbox creator guy talks about it
20:06:16 <geist> apparently it started with a crappy board layout that was too big
20:06:21 <geist> and then they had to wrap a huge controller around it
20:06:35 <drakonis> the rerelease is a injoke and the name is after brett scneff's son
20:06:51 <variable> o
20:07:00 <drakonis> at least they relocated some of that size in the xbox 360 controller
20:07:07 <drakonis> the back got fatter but it got easier to handle it
20:07:22 <variable> drakonis: is xbox 360 better than xbox ?
20:07:27 <geist> i honestly think the duke is pretty comfy, and i dont even have particularly large hands
20:07:34 <drakonis> hmm, debatable
20:07:38 <variable> what's a duke?
20:07:42 <drakonis> always bet on duke
20:07:44 * variable should be serious
20:07:46 <drakonis> nukem
20:07:52 <klange> Bigass original Xbox controller.
20:07:55 <variable> o
20:08:05 <geist> 360 controller never bothered me too much either
20:08:07 <drakonis> duke is the controller named after the hardware guy's son
20:08:15 <geist> for PC stuff i use the current xbox controller and i like it just fine
20:08:21 <drakonis> the xbone controller is a++
20:08:22 <klange> Before the smaller one was introduced, the original Xbox shipped wtih an absolutely massive hunk of plastic.
20:08:25 <variable> I have a gamecube controller I use for the desktop
20:08:29 <variable> other than that - the keyboard
20:08:34 <drakonis> the ds4 is sss
20:08:37 <drakonis> the finest
20:08:41 <klange> Opinions on the duke have been divisive.
20:08:52 <variable> ds4 ?
20:09:35 <drakonis> dualshock 4
20:09:38 <drakonis> the ps4's controller
20:09:41 <variable> o
20:10:24 <geist> which i like just fine too, i get a little cramped after hours of playing on it, but then you should stop
20:10:35 <drakonis> ^
20:10:48 <variable> lol
20:11:20 <geist> controllers i can think of i didn't like: N64. dreamcast is fairly debatable. gamecube... ehhh. SNES Advantage
20:11:26 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
20:11:43 <geist> i lvoe dreamcast but the controller is a bit harsh. has some hard angles on it iirc
20:11:51 <geist> same with the original gamecube
20:12:03 <drakonis> the long lost predecessor to the duke
20:13:45 <drakonis> the VMU was a killer idea
20:13:58 <drakonis> maybe if it was done today with the vastly better hardware
20:14:00 <geist> yeah i still have a VMU somewhere
20:14:11 <drakonis> the gimmick would run stale though
20:14:16 <geist> i still have my dreamcast with eth, keyboard, mouse, and some hacked up serial port
20:14:21 <geist> you could osdev on it, actually
20:14:34 <geist> i have some disc that does a serial load off it
20:15:46 <Mutabah> fanceh
20:16:00 <drakonis> fanceh toyes
20:16:01 <Mutabah> Related, I should linux my switch
20:16:11 <Mutabah> and then go searching for a GBA emulator
20:16:21 <geist> there is a dreamcast port of netbsd at the time. though in general its hard to do much with it: no easy hard drive interface, 16MB ram. your best bet was to NFS root it
20:16:25 <Mutabah> Switch+Linux+VBAM = awesome
20:16:26 <geist> in which case it actually sort of works okay
20:16:34 --- quit: Affliction` (Quit: Read error: Connection reset by beer)
20:16:38 <drakonis> Mutabah, hello friend
20:16:43 <drakonis> may i interest you in some retroarch
20:16:52 <geist> also DC had a VGA port you could get for it.so it was at the time (1999) by far the most PC like thing you could get
20:16:56 <geist> from a controller
20:17:00 <geist> er console
20:17:42 <klange> PS2 had a Linux distro so it could be sold as a computer instead of a game console in parts of Europe.
20:17:46 <drakonis> hmm, you know what's great about modern consoles?
20:17:57 <drakonis> they all run regular hardware
20:18:03 <geist> indeed. as well as the PS3. i kick myself for finally installing a new version of the firmware that killed the other os thing on my second PS3
20:18:06 <drakonis> so now things like qemu can emulate them
20:18:08 <geist> thus rendering it useless
20:18:45 <drakonis> the ps3 emulator runs the llvm jit
20:19:29 <drakonis> the switch runs arm, so half the work is done
20:19:50 <drakonis> https://twitter.com/yuzuemu/status/990386785380454400 super sweet.
20:19:51 <bslsk05> ​twitter: <yuzuemu> yuzu boots its first Switch exclusive, 1-2-Switch! Not all changes are in master yet, but should be soon! https://pbs.twimg.com/media/Db6PR7JUwAAlVGL.jpg
20:20:18 <pikhq> I'm reasonably sure that, while the CPUs are normal, other important parts of the hardware are at least not otherwise emulated, meaning a lot of research needs to happen.
20:20:26 <drakonis> oh yeah, that's still a thing
20:20:27 <pikhq> Like, the all important GPU needs emulating.
20:20:30 <drakonis> ^^
20:20:37 <drakonis> won't deny the need for that
20:20:53 <drakonis> the nvidia bits are still a secret
20:20:57 <pikhq> Still, having certain parts be really well-understood helps a bit.
20:21:04 <drakonis> indeed
20:24:24 <drakonis> i do like that i can run demon souls on my computer
20:24:52 <drakonis> never allow demon souls to die
20:26:12 <geist> i did fiddle around with sonys 'stream a PS3 playing stuff to your PS4' service a bit
20:26:22 <geist> seems to work fairly well for non super twitchy things if you have a good internet
20:26:51 <geist> must be an interesting hardware setup back at some colo. presumably tons of rackmount PS3s
20:27:11 --- join: Affliction (affliction@2600:3c01::13:ffff) joined #osdev
20:27:29 <drakonis> they must have some kind of emulator thing
20:27:49 <drakonis> likely to be some horrible abomination thanks to the cell ppc arch
20:28:16 <geist> could be, but it looks fine
20:29:55 <drakonis> huh you can run psnow on pc
20:29:57 <drakonis> who'd think
20:30:04 <drakonis> this is new
20:30:25 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
20:30:26 <geist> oh that's interesting
20:30:55 <geist> yeah sure enough. makes sense of course
20:31:08 <drakonis> this seems like an expansion of onlive
20:31:31 <geist> looksl ike they awnt you to buy the dualshock for PC, so maybe that's the in
20:31:39 <drakonis> well i already own one
20:31:50 <drakonis> not a big deal to me since it is a decent controller for emulation
20:31:59 <geist> iirc there's some mechanism (on PS4) to upload PS3 save games to it too
20:31:59 <drakonis> its the best thing for playing the majority of retro games
20:34:19 --- quit: sixand (Ping timeout: 245 seconds)
20:35:16 --- quit: Griwes (Ping timeout: 256 seconds)
20:36:21 <drakonis> unless they already had a mechanism for sending them to sony's servers
20:36:49 <drakonis> it'd be a little tough to acquire those saves for the psnow services
20:37:57 <variable> fscking hell
20:38:03 <drakonis> sup
20:38:05 <geist> ah yeah that's right. the ones you save in the cloud can be imported, that's what it is
20:38:07 <variable> rewriting some code that using K&R style var-args
20:38:11 <variable> :(
20:38:22 <drakonis> at least its not the questionable at&t style fbsd has
20:38:36 <drakonis> the questionable style that is
20:38:40 <variable> lol
20:38:43 <drakonis> i think at&t is assembly apparently?
20:38:53 <variable> AT&T is the only assembly
20:38:56 <variable> I hate intel
20:38:57 <drakonis> hmm
20:39:24 <geist> theyre both equally distasteful to me. i spend more tmie with att syntax so it's what i go with
20:39:51 <variable> fsck it
20:39:58 <variable> time to use NULL
20:40:06 <drakonis> NULL AND VOID
20:46:46 <drakonis> i'm trying to justify pimping lobsters here
20:46:47 <drakonis> with a good post
20:48:26 <doug16k> lol objdump output. --full-contents shows a4160080 ffffffff implying that it is showing 32 bit values. really the bytes are a4 16 00 80 ff ff ff ff
20:49:49 <variable> drakonis: I have a stuffed lobster
20:49:53 <variable> his name is clawdyus
20:49:56 <variable> because it is claws
20:51:17 <latentprion> I have a red lobster
20:53:22 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
20:53:26 <drakonis> sweet
20:54:20 <doug16k> it seems the addend for R_X86_64_RELATIVE RELA entries is always equal to the initial value at that location. should I be calculating the new value based on the addend and ignoring the value at the location, or just ignoring the addend and adding the difference in base address to the value at that location?
20:54:53 * klange sighs
20:55:00 <klange> I... should write an ELF64 loader...
20:55:12 <geist> https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md this is nice. i like this format
20:55:14 <bslsk05> ​github.com: riscv-elf-psabi-doc/riscv-elf.md at master · riscv/riscv-elf-psabi-doc · GitHub
20:55:21 <geist> just dropping it right out there so you dont have to dig through pdfs or whatnot
20:55:29 <geist> but can still sync it locally with git
20:56:04 <geist> the register layout is a bit wonky, but i guess they were designing for the 16 register compressed ABI as well
20:56:14 <geist> so they have the two blocks of temporary and saved
20:56:36 <geist> also interesting they name their registers x like arm64 did. arm64 is no longer the weird one there
20:56:52 <doug16k> the elf spec says B + A, but that is obviously not correct for PIE, unless their definition of "the base address which it was loaded" being zero when loaded at its natural (unrelocated) location
20:57:11 <geist> i'm fairly certain you should add yes
20:57:30 --- quit: sixand (Remote host closed the connection)
20:57:49 <geist> and of course that's the difference between the REL and RELA, the As have the additional +
20:57:53 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:58:04 <Mutabah> geist: Iirc REL/RELA is just about where the A is stored
20:58:18 <Mutabah> With REL it's in the target, with RELA it's in the relocation entry
20:58:26 <geist> hmm, okay well you're probably right
20:58:29 <geist> so never mind!
20:58:29 <doug16k> so for PIE, "B" is actually the difference in the base address - the distance the addresses have been shifted from their natural location?
20:58:39 <geist> I dont know everything. I only know what I know
20:59:52 <drakonis> apparently lobsters owns the lobster emoji
21:00:51 <doug16k> Mutabah, implying that I ignore the value at that location with RELA, and purely compute it from B and the addend? ok
21:00:59 <Mutabah> doug16k: Yep
21:01:27 --- quit: nj0rd (Ping timeout: 240 seconds)
21:02:15 --- quit: ALowther (Ping timeout: 260 seconds)
21:07:44 <drakonis> https://www.youtube.com/watch?v=9T1vfsHYiKY
21:07:45 <bslsk05> ​'Shagged by a rare parrot - Last Chance To See - BBC Two' by BBC (00:02:32)
21:08:09 <drakonis> austin powers: the parrot that shagged me
21:08:35 <drakonis> now then, i think i should go
21:08:39 <drakonis> good night folks
21:14:37 --- quit: drakonis (Read error: Connection reset by peer)
21:16:20 --- join: nj0rd (~nj0rd@i577BC0BF.versanet.de) joined #osdev
21:19:18 --- quit: freakazoid0223 (Quit: Do fish get thirsty?)
21:22:48 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
21:30:23 --- join: oaken-source (~oaken-sou@p3EE2D1BD.dip0.t-ipconnect.de) joined #osdev
21:45:01 --- quit: lf94 (Ping timeout: 260 seconds)
21:48:28 <izabera> i'm reading the x64 abi and i'm confused by a thing
21:48:50 <izabera> the initial register state described in 3.4.1
21:49:30 <izabera> "%rdx a function pointer that the application should register with atexit (BA_OS)."
21:53:21 <izabera> i'm not sure who should do that
21:53:36 <izabera> i mean registering things with atexit
21:53:41 <Mutabah> That's an interesting item, where's it from?
21:53:49 <Mutabah> (link?)
21:53:58 <quul> isn't atexit a libc thing?
21:54:11 <izabera> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
21:54:12 <bslsk05> ​github.com: X86 psABI · hjl-tools/x86-psABI Wiki · GitHub
22:00:45 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
22:05:16 --- quit: pounce (Quit: WeeChat 2.1)
22:13:20 --- quit: variable (Quit: /dev/null is full)
22:13:35 --- quit: lachlan_s (Quit: Connection closed for inactivity)
22:14:53 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
22:15:09 --- quit: sixand (Ping timeout: 245 seconds)
22:15:09 --- nick: sixand1 -> sixand
22:15:15 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:21:01 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
22:22:03 --- quit: sixand (Ping timeout: 260 seconds)
22:32:06 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
22:36:26 --- quit: sixand (Ping timeout: 252 seconds)
22:41:14 <quul> izabera: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S;hb=HEAD#l41 but don't ask me how it gets that from _init: PREINIT_FUNCTION define
22:41:16 <bslsk05> ​sourceware.org: sourceware.org Git - glibc.git/blob - sysdeps/x86_64/start.S
22:41:27 --- quit: NaNkeen (Ping timeout: 245 seconds)
22:43:12 <quul> or is _start before _init i don't have x86_64 i just looked on i386 and the first two instructions lined up
22:47:39 <quul> ah yeah _start is first, doy
22:49:58 --- join: NaNkeen (~nankeen@123.136.106.79) joined #osdev
22:50:21 --- join: `Guest00000 (~user@37.113.160.53) joined #osdev
22:54:57 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
23:08:54 --- quit: NaNkeen (Ping timeout: 245 seconds)
23:09:44 --- quit: w41 (Ping timeout: 245 seconds)
23:21:57 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
23:23:07 --- quit: sixand (Ping timeout: 245 seconds)
23:27:29 --- quit: magnificrab (Remote host closed the connection)
23:28:09 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
23:36:49 --- quit: mavhq (Read error: Connection reset by peer)
23:37:55 <izabera> https://i.imgur.com/W5H6FbO.png guess who is not having fun
23:38:06 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
23:38:28 <Mutabah> ouch
23:38:45 <izabera> the worst part is that i'm kinda getting used to this bullshit
23:38:55 <geist> what are you trying to debug there?
23:39:36 <izabera> just a hello world and i tried to register the atexit thingy
23:39:40 <geist> ah
23:40:47 <klange> Thanks for flying Vim.
23:40:52 <izabera> you're welcome
23:42:17 <klange> get yourself a PS1 that sets your titlebar, will stop Vim from shitting on it
23:43:04 <izabera> i don't actually use the titlebar very often
23:43:24 <izabera> besides, i'd rather stop vim from shitting on it in the first place
23:44:33 <izabera> something was broken before the crash
23:44:34 <aalm> :D
23:44:44 <aalm> titlebar? what's that
23:45:03 <izabera> gdb didn't show the source line for main
23:45:04 <aalm> just slim frames<3
23:45:16 <klange> I've gone and gunked my terminal up with an added *menubar* https://i.imgur.com/vwVV7sG.png
23:45:29 <klange> soon I'll be adding scrollbars and other useless features
23:45:37 <izabera> klange: now only one thing is missing
23:45:53 --- mode: ChanServ set +o klange
23:45:57 <izabera> cmon
23:46:01 <klange> ;)
23:46:07 --- mode: ChanServ set -o klange
23:46:27 <aalm> ?
23:46:52 <klange> (izabera constantly points out my lack of job control support)
23:47:15 <aalm> right, i was going to just write how it does seem to lack job control
23:48:04 --- quit: AverageJ0e (Ping timeout: 245 seconds)
23:48:08 <aalm> you got taskmanager right? xD
23:48:47 <izabera> https://arin.ga/Jr8kdk/raw am confused
23:48:53 <izabera> something is wrong with my gdb
23:49:44 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:50:17 <aalm> who needs registers, you can have variables in C!
23:51:15 --- quit: dbittman_ (Ping timeout: 276 seconds)
23:51:45 <izabera> ouch i have a reproducer for the crash
23:51:53 <izabera> it only happens in tui mode
23:52:09 <izabera> i don't even know why i keep using this buggy crap
23:52:21 <aalm> gdb?
23:52:33 <izabera> yes but more specifically, tui
23:53:45 <aalm> i've never done anything usefull with gdb, ok maybe one or two traces for someone else, but rly.. annoying thing.
23:54:00 <izabera> gdb is super useful
23:54:10 --- quit: ALowther (Ping timeout: 252 seconds)
23:54:26 <izabera> i just want it to actually do its job and not die in the middle of it
23:54:47 <aalm> +10yrs ago when i was more into debugging crap, i used iirc. ollydbg on win32, it was good:)
23:55:25 <aalm> nowadays i just trigger ddb(4) if i need to debug anything
23:55:37 <izabera> what exactly was great about it?
23:55:47 <izabera> s/reat/ood/
23:56:39 <quul> grr gdb, how the hell do you scrol back up after you pass what you're looking for, down/pg_down work but not up...
23:57:29 <aalm> i fixed the output to fasm-compatible, and it had colors! and the vs. was windbg, ofc.
23:57:30 <quul> oh it jumped into a different section
23:59:38 <aalm> izabera, so it was practically objdump to me too
23:59:55 <quul> this rtld_fini thing is weird, where does it live ld.so?
23:59:59 --- log: ended osdev/18.05.20