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=1&d=7

Sunday, 7 January 2018

00:00:00 --- log: started osdev/18.01.07
00:05:55 --- join: fodil_ (~fodil@2a01:e35:39c9:20c0:6942:96dd:2488:169f) joined #osdev
00:05:55 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:6942:96dd:2488:169f) joined #osdev
00:06:45 --- quit: Arcaelyx (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:07:54 --- quit: Belxjander (Ping timeout: 256 seconds)
00:09:40 --- join: fodil (~fodil@2a01:e35:39c9:20c0:6942:96dd:2488:169f) joined #osdev
00:09:56 --- quit: fodil (Client Quit)
00:10:55 --- join: xerpi (~xerpi@32.red-88-23-235.staticip.rima-tde.net) joined #osdev
00:10:59 --- quit: fodil_ (Quit: Leaving)
00:11:13 --- quit: davxy (Ping timeout: 268 seconds)
00:13:18 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
00:13:31 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:15:33 --- quit: sinetek (Quit: Leaving)
00:57:20 --- quit: Humble (Ping timeout: 240 seconds)
01:00:34 --- quit: Belxjander (Ping timeout: 240 seconds)
01:06:27 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:14:02 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
01:20:51 --- quit: xerpi (Quit: Leaving)
01:29:26 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
01:34:48 --- quit: Belxjander (Ping timeout: 248 seconds)
01:35:51 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
01:37:28 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:37:54 --- join: Humble (~hchiramm@223.186.43.204) joined #osdev
01:39:45 --- join: SHEjian0702 (~u0_a169@60.247.61.29) joined #osdev
01:47:47 --- quit: hmmmmmm (Remote host closed the connection)
01:55:00 --- quit: SHEjian0702 (Ping timeout: 256 seconds)
01:55:23 --- join: SHEjian0702 (~u0_a169@li998-209.members.linode.com) joined #osdev
01:56:05 --- quit: Pessimist (Ping timeout: 246 seconds)
02:11:50 --- quit: regreg_ (Ping timeout: 240 seconds)
02:15:44 --- quit: SHEjian0702 (Remote host closed the connection)
02:22:18 --- join: SHEjian0702 (~u0_a169@60.247.61.29) joined #osdev
02:27:02 <promach> anyone worked on https://sel4.systems/About/seL4/ before ?
02:27:05 <bslsk05> ​sel4.systems: About seL4 | seL4
02:30:50 --- quit: SHEjian0702 (Ping timeout: 265 seconds)
02:30:56 <latentprion> /join #sel4
02:32:46 --- join: dennis95 (~dennis@p50915CBC.dip0.t-ipconnect.de) joined #osdev
02:33:44 --- join: SHEjian0702 (~u0_a169@li823-193.members.linode.com) joined #osdev
02:34:05 <latentprion> promach: Any particular reason for your interest in seL4 btw?
02:36:50 <promach> latentprion: I am interested in learning how to formally prove a kernel as in https://github.com/seL4/l4v
02:36:51 <bslsk05> ​seL4/l4v - seL4 specification and proofs (31 forks/171 watchers)
02:37:25 <latentprion> Ah, well there'll be a formal methods engineer in #seL4 tomorrow from about 10am sydney time
02:37:47 <latentprion> He'll gladly answer your questions
02:42:17 --- quit: SHEjian0702 (Remote host closed the connection)
02:44:15 <promach> latentprion: thanks for the irc channel suggestion
02:44:30 <latentprion> i got u fam
02:46:40 --- join: SHEjian0702 (~u0_a169@60.247.61.29) joined #osdev
02:46:57 --- quit: Asu (Quit: Konversation terminated!)
02:58:03 --- join: u0_a169 (~u0_a169@60.247.61.29) joined #osdev
03:01:10 --- quit: SHEjian0702 (Ping timeout: 248 seconds)
03:01:16 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
03:02:15 --- join: m_t (~m_t@p5DDA0D74.dip0.t-ipconnect.de) joined #osdev
03:06:01 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
03:10:10 --- join: dhoelzer (~dhoelzer@ool-4a5940e5.dyn.optonline.net) joined #osdev
03:12:09 --- quit: u0_a169 (Remote host closed the connection)
03:22:19 --- quit: Pessimist (Ping timeout: 264 seconds)
03:36:05 --- quit: Sjors (Quit: http://quassel-irc.org - Chat comfortabel. Waar dan ook.)
03:36:18 --- join: Sjors (~quassel@bulbasaur.sjorsgielen.nl) joined #osdev
03:38:15 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
03:38:50 --- quit: Asu (Client Quit)
03:40:55 --- quit: dhoelzer (Ping timeout: 265 seconds)
03:42:52 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
03:42:52 --- quit: Asu (Remote host closed the connection)
03:43:50 --- quit: osa1 (Ping timeout: 248 seconds)
03:44:45 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
03:52:18 --- quit: immibis (Ping timeout: 256 seconds)
03:55:29 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
03:56:00 --- quit: alphawarr1or (Quit: Connection closed for inactivity)
03:58:24 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-lzmnkapiwmvvuvse) joined #osdev
04:03:55 --- quit: rain1 (Quit: WeeChat 2.0.1)
04:06:23 --- quit: daniele_athome (Ping timeout: 260 seconds)
04:06:46 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
04:06:49 --- quit: FreeFull ()
04:08:40 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
04:15:12 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
04:15:19 --- join: silipwn (~silipwn@111.93.99.180) joined #osdev
04:15:20 --- quit: silipwn (Changing host)
04:15:21 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
04:21:43 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
04:29:42 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
04:30:05 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
04:35:54 --- quit: Shamar (Quit: Lost terminal)
04:38:14 --- quit: Belxjander (Ping timeout: 248 seconds)
04:38:46 --- quit: silipwn (Ping timeout: 248 seconds)
04:44:56 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:45:28 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:54:29 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
04:57:17 --- quit: Belxjander (Ping timeout: 265 seconds)
05:00:36 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:01:58 --- quit: Asu (Read error: Connection reset by peer)
05:05:24 --- join: ouyes (~ouyes@125.69.40.188) joined #osdev
05:07:19 <ouyes> thePowersGang, I remember you did a study on image, what is it about in details?
05:18:07 --- quit: osa1 (Ping timeout: 264 seconds)
05:20:48 <glauxosdever> Mutabah: ^
05:23:29 --- quit: ouyes (Remote host closed the connection)
05:23:53 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-pcxuukygccfkvocm) joined #osdev
05:28:39 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
05:29:54 <Mutabah> I wonder what they were referring to
05:30:04 <Mutabah> glauxosdever: Don't worry next time, I still have a hilight rule set up for that name
05:30:10 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
05:30:14 --- quit: heat (Remote host closed the connection)
05:31:31 <rain1> https://github.com/0xAX/linux-insides/blob/master/Booting/linux-bootstrap-6.md
05:31:32 <bslsk05> ​github.com: linux-insides/linux-bootstrap-6.md at master · 0xAX/linux-insides · GitHub
05:34:48 --- join: bcos (~bcos@1.123.1.51) joined #osdev
05:34:49 --- quit: bcos_ (Read error: Connection reset by peer)
05:35:06 --- join: John___ (~John__@79.97.140.214) joined #osdev
05:37:22 --- quit: John___ (Remote host closed the connection)
05:37:31 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
05:40:29 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
05:54:48 --- quit: Asu (Ping timeout: 265 seconds)
05:57:42 --- quit: FreeFull (Ping timeout: 265 seconds)
06:01:05 --- quit: heat (Ping timeout: 265 seconds)
06:01:06 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
06:01:41 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
06:04:51 --- join: lowl3v3l (~lowl3v3l@dslb-088-075-089-098.088.075.pools.vodafone-ip.de) joined #osdev
06:05:38 --- quit: Humble (Ping timeout: 246 seconds)
06:08:52 --- quit: m_t (Quit: Leaving)
06:09:40 --- join: unixpickle (~alex@2601:645:8103:60b6:b055:5329:a001:9a6f) joined #osdev
06:09:47 --- join: tavish (~tavish@unaffiliated/tavish) joined #osdev
06:11:37 --- quit: selfReferentialN (Ping timeout: 260 seconds)
06:20:11 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:20:20 --- quit: Belxjander (Ping timeout: 240 seconds)
06:23:19 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
06:25:26 --- quit: daniele_athome (Ping timeout: 248 seconds)
06:27:25 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:31:05 --- join: oaken-source (~oaken-sou@p3E9D3A2F.dip0.t-ipconnect.de) joined #osdev
06:36:39 --- join: oaken-so1rce (~oaken-sou@p3E9D3B51.dip0.t-ipconnect.de) joined #osdev
06:39:14 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
06:39:40 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-wudxtxffglucdmgm) joined #osdev
06:39:43 --- quit: oaken-source (Ping timeout: 264 seconds)
06:43:42 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
06:44:04 --- quit: silipwn (Client Quit)
06:48:22 --- quit: sdfgsdf (Ping timeout: 248 seconds)
06:57:23 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
06:57:43 --- quit: Halofreak1990 (Ping timeout: 264 seconds)
06:58:40 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
06:58:44 --- quit: tavish (Ping timeout: 256 seconds)
07:04:13 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
07:06:57 --- quit: CheckDavid (Quit: Connection closed for inactivity)
07:25:49 --- nick: oaken-so1rce -> oaken-source
07:26:13 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
07:38:44 --- quit: Asu (Quit: Konversation terminated!)
07:40:06 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
07:44:12 --- quit: Asu (Remote host closed the connection)
07:49:19 --- quit: apetresc (Ping timeout: 264 seconds)
07:50:02 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
07:50:07 --- quit: frolv (Remote host closed the connection)
07:50:41 --- join: apetresc (~apetresc@2607:fea8:569f:fc73:52e5:49ff:fec9:2339) joined #osdev
07:54:50 --- quit: Pessimist (Remote host closed the connection)
07:57:20 --- join: frolv (~frolv@CPE00fc8d4905d3-CM00fc8d4905d0.cpe.net.cable.rogers.com) joined #osdev
08:01:17 --- quit: multi_io (Read error: Connection reset by peer)
08:01:24 --- join: multi_io_ (~olaf@x4db3cf3e.dyn.telefonica.de) joined #osdev
08:03:55 --- quit: Retr0id (Remote host closed the connection)
08:03:59 --- quit: rain1 (Quit: WeeChat 2.0.1)
08:05:22 --- quit: Asu (Quit: Konversation terminated!)
08:06:00 --- quit: alphawarr1or (Quit: Connection closed for inactivity)
08:06:27 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
08:14:02 --- join: navidr (uid112413@gateway/web/irccloud.com/x-fslkuwbikqoqduec) joined #osdev
08:15:45 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
08:17:57 --- quit: fodil__ (Quit: Leaving)
08:26:32 --- quit: rubenwardy (Quit: Head detached)
08:27:24 --- join: rubenwardy (~rubenward@unaffiliated/rubenwardy) joined #osdev
08:27:26 --- join: xerpi (~xerpi@32.red-88-23-235.staticip.rima-tde.net) joined #osdev
08:30:49 --- nick: Asu -> Asu`afk
08:33:18 --- part: rubenwardy left #osdev
08:34:30 --- quit: m3nt4L (Quit: Leaving)
08:35:18 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-waggczbedncrsgma) joined #osdev
08:38:16 --- join: Desetude (6d9bb573@gateway/web/freenode/ip.109.155.181.115) joined #osdev
08:39:00 --- join: tacco\unfoog (~tacco@dslb-084-056-126-077.084.056.pools.vodafone-ip.de) joined #osdev
08:42:05 <Desetude> Would a functional GUI be a reasonable goal for 100 hours of work if making an OS from scratch with no knowledge of how to make them (assuming knowledge of C, asm), or would it require much less/more time?
08:44:03 <graphitemaster> I mean I put together a simple UI in games/engines in like 10 hours so it does not seem unreasonable
08:44:21 <heat> if you just want a worthless GUI, then sure
08:44:55 <heat> a complete-ish OS with a GUI requires a lot more work though
08:45:57 --- join: qeos|2 (~qeos@ppp158-255-171-31.pppoe.spdop.ru) joined #osdev
08:46:35 <heat> Desetude: functional GUI is a really vague term
08:47:17 <graphitemaster> I mean yeah, a very good UI with all the widgets and ability for people to compose widgets
08:47:32 <graphitemaster> with retained state and all that
08:47:37 <graphitemaster> that's going to take more than 100 hours
08:47:57 <heat> graphitemaster: but does he want a full OS or just a rather empty and useless shell?
08:48:43 --- quit: qeos (Ping timeout: 260 seconds)
08:48:56 --- quit: zwliew (Quit: Connection closed for inactivity)
08:49:09 --- join: rosset (~Filipe@200.150.164.149) joined #osdev
08:49:10 --- quit: rosset (Changing host)
08:49:10 --- join: rosset (~Filipe@fedora/rosset) joined #osdev
08:49:13 <heat> A complete kernel that has all the nooks and crannies a kernel should have vs or just a quick and dirty gui library inside the kernel
08:49:43 <heat> those 2 are *quite* different
08:50:01 <graphitemaster> if you have knolwedge of OS dev and GUI dev, I don't think it's unreasonable to throw together a quick microkernel + gui toolkit + vesa/bosch vga driven desktop
08:50:23 <graphitemaster> 100 hours seems reasonable idk
08:50:26 <heat> Well, he stated he doesn't.
08:50:40 <graphitemaster> yeah without the knolwedge it'll be more like 600 hours
08:50:49 <heat> or more, actually
08:51:09 <graphitemaster> can always port an existing UI toolkit
08:51:36 --- quit: ampotos_ (Ping timeout: 248 seconds)
08:51:57 <heat> I have my current OS for 2 years and it's still lacking some features needed for a GUI
08:52:20 <graphitemaster> yeah but you don't work on the minimal feature set needed, you get side tracked into other things
08:52:24 <heat> (actually, more like a display server)
08:52:26 <graphitemaster> if you just did the absolute minimal kernel :P
08:52:35 <graphitemaster> and focused on the frontend aspect then
08:52:38 <graphitemaster> you'd have it right now
08:52:45 <heat> Yeah, maybe
08:53:21 <heat> like right now, instead of adding a GUI I'm adding shared library support
08:53:39 <heat> it's redundant for the GUI end goal
08:55:54 <Desetude> I'm just trying to think of what I could achieve in 100 hours, as it is the minimum to spend on the school project I'm doing (which I chose making an OS for).
08:56:28 <heat> a basic POSIX compliant system maybe?
08:56:55 <Desetude> oh yea
08:56:59 <Desetude> That could work
08:57:01 <heat> it's still pretty impressive and you might squeeze it in 100 hours
08:57:16 <heat> if you're fairly quick at doing things
09:00:56 --- quit: Shamar (Quit: Lost terminal)
09:01:35 --- join: ampotos (~ampotos@lew31-1-78-247-114-197.fbx.proxad.net) joined #osdev
09:03:10 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:04:46 <Desetude> 100 hours was just an absolute minimum, I'm probably more likely to spend like 300 hours on the OS
09:05:14 --- quit: rosset (Quit: Leaving)
09:05:30 <Desetude> The only reason for my choice of a GUI was that it would look better to a marker of the project
09:06:06 <heat> Desetude: You can always just make a unix system and see what you can reach
09:06:15 <heat> maybe you'll have enough time for a simple gui
09:06:56 --- quit: sprocklem (Ping timeout: 246 seconds)
09:07:45 <sham1> Yeah, no need to rush. The fact that you can even get a shell to work even on a text mode is probably more than impressive enough for a high grading
09:08:13 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:e0f3:1e3c:b677:51c4) joined #osdev
09:08:33 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
09:09:25 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
09:09:42 <Desetude> Yeah, you're probably right
09:12:27 <heat> Desetude: If I were you, I'd try to do something close to xv6 before attempting something with a GUI
09:13:18 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
09:13:51 <sham1> I mean, to get to the point where you have most POSIX implemented in a good enough manner to get the shell to work, not to mention such things as having your kernel support disks and such takes its own share of effort
09:13:52 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
09:15:12 <Desetude> heat: After looking at xv6, I might try to do that
09:15:22 <__pycache__> posix sux!!!!!!!!!!!!
09:15:31 <heat> __pycache__, no
09:15:34 <__pycache__> no u
09:15:39 <heat> no u
09:15:43 <__pycache__> no, u
09:15:48 <heat> , no, u
09:15:58 <__pycache__> you win idc
09:16:10 <__pycache__> i don't like posix, it's too crufty for 2017
09:16:13 <heat> I WinMain
09:16:18 <__pycache__> lol windows
09:16:41 <heat> __pycache__: Meh, depends on what API you're talking about
09:16:45 <variable> POSIX is full of bugs
09:16:48 <__pycache__> most APIs
09:16:49 <heat> linux's API sucks
09:16:50 <variable> or bad design deecisions
09:16:55 <variable> :(
09:17:03 <variable> but to be clear
09:17:03 <__pycache__> UNIX is the best out of the worst
09:17:05 <variable> APIs suck
09:17:11 <variable> computers suck
09:17:13 <variable> humans suck
09:17:18 <__pycache__> APIs don't suck if you implement them well
09:17:22 * variable deletes __pycache__
09:17:22 <heat> /proc sucks
09:17:30 <__pycache__> i think versioned APIs make sense
09:17:35 <sham1> HURD sucks
09:17:39 <__pycache__> how about this idea?
09:17:41 <variable> TOD is perfect
09:18:13 <heat> How about we implement our APIs in shared libraries, which then invoke syscalls that may change whenever we want?
09:18:25 <heat> and then our APIs are versioned because versioned symbols exist
09:18:30 <__pycache__> int main(int argc, char **argv) { POSIX_API(5); /* or something like that */ ...initialize... some_posix_function(abc, def); .... return 0; }
09:19:08 <__pycache__> then the shared lib checks for the right variable, and does the right thing for that specific version
09:19:19 <__pycache__> 100% backwards compatibility
09:19:20 <heat> __pycache__: that sounds buggy as hell
09:19:23 <sham1> ^
09:19:24 <__pycache__> how come?
09:19:35 <variable> heat: many/most OSes do that
09:19:39 <heat> supporting multiple versions, some of which might have bad bugs
09:19:41 <variable> apple in particular
09:20:01 <__pycache__> heat: i urge you to take a look at the BUGS section of $posix_func
09:20:18 <__pycache__> getc is still there because of POSIX
09:20:31 <__pycache__> set POSIX_API to something new and now it won't exist! hooray
09:21:18 <sham1> Speaking of POSIX, I fear the day when I will have to start doing POSIX stuff just to keep GCC happy
09:21:35 <heat> __pycache__: Uh, what's the problem with getc?
09:21:41 <heat> sham1: like what?
09:21:42 <__pycache__> uh sorry
09:21:46 <__pycache__> i meant gets
09:21:52 <__pycache__> brainfreeze
09:22:43 <variable> I wouldn't mind seeing gets() just deleted from the face of the earth
09:22:45 <__pycache__> man 3p gets
09:22:56 <variable> s/p//
09:23:00 <sham1> heat: well, there are the minimum things it requires not only of your libc but it also assumes that you have some sort of POSIXy thing there, whether native or translator layer
09:23:00 <__pycache__> nope
09:23:07 <__pycache__> variable: that's the posix version of the manpage
09:23:13 <__pycache__> $ man 3p gets
09:23:15 <variable> __pycache__: don't see a '3p' section on any system I use
09:23:20 <__pycache__> huh
09:23:25 <__pycache__> you don't have posix docs then
09:23:29 <__pycache__> it works on my machine
09:23:51 <variable> either way
09:23:54 <variable> fsck gets
09:23:59 --- join: raphaelsc (~utroz@187.114.9.239) joined #osdev
09:24:10 <heat> __pycache__: POSIX 2008 was made before gets was removed from the standard(C11)
09:24:18 <__pycache__> heat: good
09:24:20 <heat> sham1: like what?
09:24:30 <__pycache__> i mean good that it got removed
09:24:38 <sham1> What do you mean "like what"
09:24:48 <heat> what does it require that's really posix?
09:24:51 <__pycache__> i'm thinking of just implementing a POSIX shim for applications that require it
09:24:53 <variable> FreeBSD recently removed 'gets'
09:24:56 <variable> IIRC
09:24:57 <__pycache__> and using my own libc otherwise
09:25:05 <__pycache__> variable: recently, lol
09:25:25 <variable> __pycache__: what's so funny?
09:25:27 <sham1> Stuff like fork(), execve() and such
09:25:33 <heat> as far as I'm aware gcc only really assumes posix when you say you're posix
09:25:38 <sham1> Hmm
09:25:40 <sham1> Does it?
09:25:47 <variable> by yeah, gcc works on non-posix systems
09:25:49 <variable> same with clang
09:25:53 <sham1> Oh good
09:26:23 <sham1> So I don't need to make some weird shim ontop of asynchronous messages just to get something like that working
09:26:26 <heat> sham1: you probably want to check out mingw code and configs
09:26:34 <sham1> Yeah, I think I should
09:26:44 <variable> __pycache__: not that we removed usage of gets; removed it entirely from the system
09:27:00 <__pycache__> good work
09:27:03 <sham1> So they now only have something like gets_s?
09:27:09 <heat> GCC is incredibly... undocumented on gcc target configs
09:27:30 <heat> Want to enable per-thread stack canaries? good luck
09:27:31 <sham1> I wouldn't be surprised if there was one paragraph in some info-page
09:27:42 <__pycache__> by the way, what is the right way to go when implementing a microkernel?
09:27:44 <sham1> In the middle of nowhere
09:27:59 <heat> __pycache__: right way to go?
09:28:10 <sham1> Well, I at least will go async because it fascinates me
09:28:10 <__pycache__> i mean, how to structure the system exactly
09:28:10 <heat> in terms of API?
09:28:25 <sham1> Async IPC messaging will be the lowest primitives for doing anything
09:28:46 <__pycache__> for example i have a vga driver in arch/i386/vga/ right now, that has to be separated into a service right?
09:28:50 <heat> I mean, microkernels kinda just work like program -> kernel -> server and back
09:29:11 <heat> __pycache__: you probably wanna keep some basic things inside the kernel
09:29:23 <__pycache__> something like linux' earlycon?
09:29:30 <heat> but yeah complex vga stuff(beyond a simple print function) will go into a service
09:29:36 <heat> maybe, never heard of that
09:29:55 <__pycache__> early console which can be routed over rs232
09:30:04 --- quit: quc (Remote host closed the connection)
09:30:13 <sham1> Some stuff probably needs to go into a kernel. I'll probably have a simple "print a string onto COM1" for debug purposes
09:30:16 <heat> the kernel should have things like memory management and raw arch things(like APIC code, etc)
09:30:19 --- join: quc (~quc@host-89-230-164-93.dynamic.mm.pl) joined #osdev
09:30:21 <__pycache__> it has print, basic newline and scroll support, setting colors and moving to a specified function
09:30:38 <__pycache__> heat: abstracting the CPU is the kernel's job i guess
09:30:43 <__pycache__> 'CPU driver service'
09:30:57 <sham1> Something about scheduling and some memory management
09:31:24 <__pycache__> yeah i think scheduling and MM is all i need in the kernel, along with cpu abstraction
09:31:26 <heat> __pycache__: Not just that, but some things really only make sense when done by the kernel(like memory management)
09:31:34 <__pycache__> heat: yep, that will be built in
09:31:42 --- quit: Desetude (Ping timeout: 260 seconds)
09:31:48 <heat> also, timers
09:31:55 <__pycache__> as in PIT?
09:32:02 <sham1> Ehh... I don't know
09:32:08 <heat> PIT, Local APIC timer, HPET, TSC
09:32:14 <heat> ACPI PM timer
09:32:18 <heat> Oh also, ACPI
09:32:18 <__pycache__> can't I just make a service that maps into the correct IRQs and such?
09:32:22 <sham1> A timer thing could probably be made into a message
09:32:29 <__pycache__> are you thinking it's got to do with latency?
09:32:39 <heat> __pycache__: And introduce more overhead on something that needs to be precise?
09:32:44 <__pycache__> yeah
09:32:55 <__pycache__> everything that needs to be fast goes into the kernel
09:33:13 <__pycache__> as in perf critical
09:33:21 <heat> every timer that != TSC is slow as hell to access, *especially* with VMs
09:33:50 <heat> Also, no POSIX-like or Win32-like API
09:34:11 <__pycache__> heat: but for other things, the kernel can expose a driver API which allows to map to IRQs, message-based interrupts, etc. right?
09:34:53 <heat> __pycache__: Yes
09:35:44 <heat> but some of those things are really up to you
09:36:43 --- join: rubenwardy (~rubenward@unaffiliated/rubenwardy) joined #osdev
09:36:56 <__pycache__> i want as little things in the kernel as possible
09:37:43 <heat> Well yeah, but some things are so simple that you really don't want them as a service
09:37:56 <__pycache__> like what?
09:38:19 --- quit: regreg_ (Remote host closed the connection)
09:38:38 <__pycache__> at boot, the kernel abstracts the CPU, sets up VMM, sets up the kernel thread and launches the services, then starts init right?
09:38:42 <heat> __pycache__: i.e: Mapping MSI interrupts https://github.com/heatd/Onyx/blob/staging/kernel/arch/x86_64/irq.c#L130
09:38:43 <bslsk05> ​github.com: Onyx/irq.c at staging · heatd/Onyx · GitHub
09:38:44 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
09:38:48 --- join: tavish (~tavish@unaffiliated/tavish) joined #osdev
09:39:10 <heat> that's all you need to map an MSI, compare a simple function call vs having to context switch just to run that small piece of code
09:39:51 <heat> It would pretty useless to run that as part of a service
09:40:25 <heat> __pycache__: you see what I mean?
09:40:33 <__pycache__> wouldn't that be part of the kernel API like I described?
09:40:52 <heat> yes
09:40:57 <__pycache__> okay
09:41:10 <__pycache__> i mean trivial things could be put in, but I'm a purist
09:41:32 --- join: elderK (uid205007@pdpc/supporter/active/elderk) joined #osdev
09:41:34 <heat> then (I assume) you also want an API to add a bus, add devices, register drivers, etc
09:41:50 <__pycache__> yes
09:42:42 <heat> To kinda quote sortie(because I don't have the original quote), "It's hard to get a microkernel right"
09:42:55 <__pycache__> look at HURD
09:43:03 <heat> HURD LUL
09:43:10 <__pycache__> this is just gonna be a hobby
09:43:21 <sham1> Yeah, maybe Mach isn't the best thing to base your design on
09:43:23 <__pycache__> something i put like 1 hour a day on after work
09:43:31 <__pycache__> sham1: macosx works?
09:43:45 <sham1> But HURD doesn't
09:43:57 <sham1> Also, as far as I am concerned, neither does MacOS, but that's just me
09:43:59 <__pycache__> what's the diff
09:44:02 <__pycache__> lol
09:44:25 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
09:45:12 <__pycache__> heat: also, i am thinking of keeping the kernel address space completely separate from userspace, keeping only what's absolutely needed by the CPU
09:45:33 <__pycache__> while this will slow down syscalls, it would prevent things like meltdown for instance
09:46:08 <__pycache__> currently here's my (almost) latest work: https://gitgud.io/m712/testos
09:46:10 <bslsk05> ​gitgud.io: John / testos · GitLab
09:46:11 <heat> __pycache__: Yes, that's probably the best course of action right now
09:46:32 --- quit: freakazoid0223 (Ping timeout: 248 seconds)
09:46:36 <heat> >GPLv3
09:46:37 <heat> ohno
09:46:40 <sham1> Oh god
09:47:50 <__pycache__> ???
09:48:01 <__pycache__> it's the kernel for sharing and caring
09:48:04 <__pycache__> license*
09:48:32 <heat> no it's the license for not sharing and caring
09:48:37 --- quit: variable (Quit: Found 1 in /dev/zero)
09:48:45 <__pycache__> how the hell
09:48:46 <heat> hell, even GPLv2 is better
09:49:02 <heat> want actual sharing and caring? MIT or BSD
09:49:03 <__pycache__> i disagree, GPL3 closes many loopholes of GPL2
09:49:17 <__pycache__> BSD allows corporate assholes to use your code however they want
09:49:25 <heat> "corporate assholes"
09:49:27 <__pycache__> I want modifications back
09:49:35 <sham1> And they'll most likely give them
09:49:48 <__pycache__> most likely, not without GPL
09:49:54 <heat> uh
09:49:55 <heat> what
09:50:10 <sham1> You do realize that it is a lot more cost-effective to push stuff upstream
09:50:21 <sham1> So they don't need to maintain their own patches, they just let you do it
09:50:35 <heat> yeah GPL won't really force anyone to give back their changes
09:50:53 <__pycache__> if they release binaries, they have to
09:50:54 <heat> they (usually) give them back
09:51:04 <__pycache__> whereas with BSD they can just push a superior version with their patches for money
09:51:18 <heat> some companies don't, but that's ok
09:51:24 <__pycache__> (without giving source code)
09:51:27 <heat> 1) Do you really care?
09:51:41 <sham1> What's wrong with "pushing for money". Also again, they'd be trying to keep up with a running target
09:51:42 <heat> 2) If the company won't give you their changes back, do you really want their code?
09:51:53 <__pycache__> heat: think GRsec
09:52:01 <__pycache__> brb dinner
09:53:44 <heat> __pycache__: what about it?
09:54:25 <heat> "Their patches are pure garbage." - Linus 2017
09:54:57 <heat> aka no one in upstream will want them
09:56:03 <heat> also, I don't see what's the problem with selling a product
09:59:00 --- join: hmmmm (~sdfgsf@pool-72-79-169-212.sctnpa.east.verizon.net) joined #osdev
09:59:21 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
09:59:29 --- quit: sortaddsort (Quit: Leaving)
10:02:35 --- quit: xerpi (Quit: Leaving)
10:03:58 --- quit: garit (Ping timeout: 260 seconds)
10:06:11 --- quit: heat (Remote host closed the connection)
10:08:31 --- join: garit (~garit@unaffiliated/garit) joined #osdev
10:08:33 --- quit: garit (Excess Flood)
10:09:08 --- join: garit (~garit@94.197.120.39.threembb.co.uk) joined #osdev
10:09:08 --- quit: garit (Changing host)
10:09:08 --- join: garit (~garit@unaffiliated/garit) joined #osdev
10:09:47 <__pycache__> *shrug*
10:10:16 <__pycache__> linus is really uncaring about kernel security
10:11:03 <__pycache__> while i do think he has a right to call their patches garbage, he needed to also help the guys help improve the garbage patches
10:13:16 --- join: unixpickle (~alex@2601:645:8103:60b6:39c2:f9b2:c9c5:8e03) joined #osdev
10:14:07 <garit> Im sure he will accept it once everything is fixed
10:14:13 --- quit: Tobba (Quit: Leaving)
10:14:32 --- join: Tobba (~Tobba@h-25-170.A159.priv.bahnhof.se) joined #osdev
10:14:54 --- quit: Asu`afk (Remote host closed the connection)
10:15:50 --- join: Pyjong (~pi@14-232-24-185.static.servebyte.com) joined #osdev
10:18:08 <Pyjong> sup
10:21:43 --- quit: awang (Ping timeout: 268 seconds)
10:23:09 --- join: Humble (~hchiramm@106.206.90.85) joined #osdev
10:25:01 --- quit: Pyjong (Quit: TinyIRC 1.1)
10:30:46 --- quit: ampotos (Ping timeout: 248 seconds)
10:30:54 --- join: Pyjong (~pi@14-232-24-185.static.servebyte.com) joined #osdev
10:31:51 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:b598:1110:e01d:953a) joined #osdev
10:34:40 --- join: ampotos (~ampotos@lew31-1-78-247-114-197.fbx.proxad.net) joined #osdev
10:35:54 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
10:37:28 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
10:40:42 --- quit: uvgroovy (Quit: uvgroovy)
10:40:51 <corecode> welp
10:42:03 <corecode> you think these specex cpu bugs make a case for or against microkernels?
10:42:22 <rain1> no
10:42:34 <bcos> Specex?
10:42:41 <corecode> speculative execution
10:42:49 <bcos> Ah - OK
10:43:09 * bcos was worried there was a new one - spectre, meltdown, the AMD PSP one, then specex :-)
10:43:15 <corecode> i mean, if you need to swap out the whole page table anyways
10:45:08 <sham1> Suddenly Elon Musk just busts through your window and makes you life a living hell with speculative execution
10:46:10 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
10:46:30 --- quit: uvgroovy (Client Quit)
10:46:45 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
10:47:26 --- join: bm371613 (~bartek@89-64-31-161.dynamic.chello.pl) joined #osdev
10:47:31 <corecode> what's musk got to do with it
10:48:07 <bcos> SpaceX -> SpeceX
10:48:21 <Pyjong> ooooooh, heheh :)
10:48:43 <corecode> aha
10:49:40 <rain1> hi
10:51:56 --- quit: Pyjong (Quit: TinyIRC 1.1)
10:52:43 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
10:53:36 --- quit: CheckDavid (Quit: Connection closed for inactivity)
10:57:01 --- join: Asu (~sdelang@AMarseille-658-1-120-247.w86-219.abo.wanadoo.fr) joined #osdev
11:01:42 --- quit: Humble (Ping timeout: 248 seconds)
11:01:43 --- join: m_t (~m_t@p5DDA0D74.dip0.t-ipconnect.de) joined #osdev
11:07:36 --- quit: davxy (Ping timeout: 248 seconds)
11:08:48 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
11:09:12 --- quit: Belxjander (Ping timeout: 256 seconds)
11:11:38 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
11:20:04 --- quit: quc (Remote host closed the connection)
11:20:16 --- join: quc (~quc@host-89-230-164-93.dynamic.mm.pl) joined #osdev
11:21:32 --- quit: Belxjander (Ping timeout: 265 seconds)
11:23:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
11:25:24 --- join: Pyjong (~pi@14-232-24-185.static.servebyte.com) joined #osdev
11:33:10 --- quit: davxy (Ping timeout: 248 seconds)
11:33:47 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
11:34:39 <Pyjong> emmm... is there some objdump/readelf way to figure out which dynamic symbol belongs to shared object?
11:36:16 <geist> well, you could dump the dynamic symbol table for all the libs you know are in the search and then figure out which one has it yes
11:36:28 <geist> both readelf and objdump have a 'dump the dynamic symbol table' switch
11:37:41 <Pyjong> but there must be some sort of reference to the .so for each symbol right? or does the dynamic linker go through all symbols of all shared objects?
11:37:57 <geist> basically the latter
11:38:35 <geist> for better or worse the way ELF linkage works the binary file itself says which libs it links against, but only at the lib level
11:38:53 <Pyjong> D:
11:38:55 <geist> and then the dynamic linker essentially searches the library list (recursively if it has to) to resolve any given symvol
11:39:43 <geist> so you have a binary like say 'ls' or whatnot that in the program header says 'i need libc.so and foo.so' and then as the dynamic linker resolves externals from ls it searches through those libs
11:40:34 <sham1> Good thing that static linkage exists
11:40:36 <Pyjong> oh, pfff ok.. thanks!
11:41:06 <geist> that being said you could i suppose invent your own mechanism like embed the library in the symbol
11:41:11 <geist> say 'printf@libc.so
11:41:45 <geist> i've seen the @something stuff before, but only for versions of symbols
11:41:53 <sham1> Or have some sort of manifest for every binary (although this might get ugly)
11:42:29 <Pyjong> that sounds actually pretty tempting
11:42:45 <rain1> I just feel like x86 is ugly..
11:42:47 <geist> i guess, it doesn't bug me at all, that gives some amount of flexibility to the loader to decide
11:42:48 <rain1> and idont wann awork on it
11:42:57 <geist> rain1: then done
11:42:58 <geist> dont
11:43:11 <geist> quit complaining and start hacking
11:43:15 <sham1> ^
11:43:58 <sham1> I, for one, like x86 for the lack of a better word
11:44:30 --- quit: jack_rabbit (Quit: Leaving)
11:44:34 <geist> i'm fairly ambivalent about it. its not pretty but once you get into the reallly really nitty gritty and have similarly advanced architectures, they *all* have warts
11:44:48 <sham1> Yeah
11:44:48 <geist> you just end up with different tradeoffs here and there
11:45:06 <sham1> Plus x86 and AMD64 are just easy to find bare metal to test on
11:45:23 <geist> for all the terrible things x86 does, there are entire sets of engineering problems you just dont have to worry about
11:45:47 <geist> mostly dealing with memory model and full cache coherency with devices. those are *big* problems to solve if you have to worry about them
11:45:52 <geist> doubleplus so with SMP
11:46:12 <doug16k> x86 memory ordering is nearly magical
11:46:27 <geist> so something like arm64 is similarly as complex as x86-64 in full on modern SMP serious OS world, and it's definitely prettier, but then you have these memory model things to worry about
11:46:33 <geist> which adds another layer of you better know what you're doing
11:46:53 <sham1> Yeah, the grass isn't always greened
11:46:58 <geist> so it's a tradeoff. i consider them about as complex as each other
11:47:12 <geist> i suspect if you had access to a high end POWER machine and hacked on it it'd be similarly complex
11:47:38 <geist> whichi s about the only other remaining architecture that has similar levels of performance and sophistication
11:48:15 <Pyjong> what's memory ordering?
11:48:34 <geist> but, with x86 the best thing you can do is get into 64bit mode and never look back. it gets a fair amount simpler there, honestly
11:49:01 <sham1> No segmentation by itself is an enough of a reward
11:49:07 <geist> right
11:49:07 <gamozo> the CPU can access memory out of order of what the instructions do, this for the current core has no detectable behavior as the processor ensures the accesses can be safely done out of order. However other cores may observe these out of order accesses and get confused
11:49:37 <geist> right, memory ordering for all practical purposes (with exceptions) is generally a problem you only see with SMP
11:49:42 <gamozo> weakly/strongly ordered refers to how aggressive these reorderings are
11:50:17 <geist> but it's everything to do with how other cpus see memory accesses from other cpus
11:51:01 --- quit: daniele_athome (Ping timeout: 265 seconds)
11:51:48 <geist> reminds me, i should sit down and debug why the kernel blows up on cortex-a72, apparently
11:51:56 <sham1> Yeah, many parts of the x86 stuff is annoying (real mode... although with that you need to be a crazy person like me to actually want to deal with it)
11:52:02 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
11:52:06 <geist> i'm dreading that it's some deep memory ordering problem, since a72 is about the most OOO arm core that i have access to
11:52:22 <sham1> But it's also not too bad once you get used to the idiosyncrasies
11:52:39 <geist> sham1: yep. remember 8086 segmentation was actually a Feature back in the day
11:52:46 --- join: daniele_athome (~daniele_a@93.40.14.81) joined #osdev
11:52:55 <geist> a clever way to get around 16 bit memory limitations, other vendors were fiddling with different mechanisms
11:53:03 <sham1> Yah
11:53:23 <geist> it was strictly better than the standard 16bit machine just having 64K of address space, period
11:53:37 <geist> ad then requiring there be external paging style hardware to swap in banks of ram (a common solution)
11:54:07 <sham1> Yeah, I don't think 8086 or the IBM PC would have gotten anywhere if it was just a glorified C64
11:54:13 <geist> x86 didn't even invent segmentation. a lot of early minicomputers and whatnot had external segmentation units that were 286 style
11:54:26 <geist> with that you can actually build a pretty functional system. early unix was developed on this sort of stuff
11:54:30 --- quit: freakazoid0223_ (Ping timeout: 252 seconds)
11:54:50 --- quit: oaken-source (Ping timeout: 268 seconds)
11:54:54 <geist> give each process 2 segments, kernel globally allocated them out of the large physical space
11:55:04 --- quit: Pyjong (Ping timeout: 248 seconds)
11:55:17 <sham1> Mm
11:55:25 <geist> hence unix signals like 'segmentation fault'
11:55:54 <graphitemaster> to be fair, you could also do segmentation without having actual segmentation, as long as you could put the kernel in it's own segmentation space, you could have it swap everything out to disk on context switch :P
11:56:12 <graphitemaster> so no more than one process was in memory at a time
11:56:14 <geist> indeed, but then that relies on a fast disk, which wasn't generally available back then
11:56:21 <sham1> Holy slowdown batman
11:56:25 <geist> or you can just copy the process in and out of the slot on every context switch
11:56:51 <graphitemaster> SSD performance has surpassed DDR3 speeds now.
11:56:56 <geist> if the kernel had some sort of sole access to the larger memory subsystem. perhaps via dedicated page-in-memory switch
11:56:58 <graphitemaster> So this may not be a terrible idea now :P
11:57:05 <sham1> How about the bus
11:57:07 <geist> graphitemaster: kinda doubt that
11:57:14 <graphitemaster> for bandwidth anyways
11:57:16 <graphitemaster> not for latency
11:57:31 <geist> DDR3 speeds with a wide enough bus completely destroys even x16 PCI
11:58:05 <graphitemaster> geist, samsung has a dual slot x16 pci nvme ssd that has 2 billion iop/s
11:58:15 <geist> sure, but what's the raw speed?
11:58:20 <geist> and can it sustain it?
11:58:22 <graphitemaster> 250GB/s
11:58:35 <geist> yes but that's already wayyy faster than x16 pcie
11:59:15 <geist> though with upcoming PCI 5 or so it may get up in that
11:59:28 <sham1> Ooooh, swap might be viable
11:59:33 <graphitemaster> PCIe3 is 5.0GT/s
11:59:45 <graphitemaster> it's dual slot PCIe3 x16 (so that's 10GT/s)
11:59:46 <geist> right, so thats 5 * 16 / 8
12:00:06 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:00:10 --- join: jack_rabbit (~jack_rabb@2601:240:8201:74f0:80ba:bf06:e018:f8b7) joined #osdev
12:00:18 <geist> so 10 * 16 (160GT/sec)
12:00:20 <geist> 8
12:00:27 <geist> divided by 8 because that's in bits
12:00:29 --- quit: tuxillo (Quit: bbl)
12:00:49 <graphitemaster> it's less actually
12:00:59 <graphitemaster> because you have to send 10 bits for every 8 bits
12:01:08 <geist> that's pcie 2
12:01:14 <graphitemaster> how does the new bus work|?
12:01:21 <geist> pcie 3 actually flips over to 128b/130b, which is why you get 8GT/sec vs 5GT/sec
12:01:26 <graphitemaster> ah that makes sense
12:01:30 <geist> changes the overhead from around 20% to something like 1.5%
12:01:46 <graphitemaster> okay so faster than DDR2, and faster than _most_ DDR3 :P
12:01:47 <geist> pcie 4 doubles the rate to 16GT/sec per lane
12:01:50 <geist> :)
12:01:57 <graphitemaster> that's still pretty damn good
12:02:01 <geist> totes
12:02:16 --- join: atrapado_ (~atrapado@unaffiliated/atrapado) joined #osdev
12:02:31 <geist> i was just looking at all of this the other day to figure out what the theoretical max of a pcie x4 NVMe card
12:02:43 <geist> which end up something like 4GB/sec
12:02:51 <geist> with pcie 3
12:02:55 <sham1> But yeah, even though x86 is rather odd and legacy, it's not too bad
12:02:56 <graphitemaster> geist, I just find it neat because gaming motherboards have riser cards that slot into slightly modified DDR3 slots to gain more m.2 for SSDs
12:03:08 <graphitemaster> that are right beside the ram slots.
12:03:25 <geist> https://en.wikipedia.org/wiki/PCI_Express#History_and_revisions has a pretty good table
12:03:26 <bslsk05> ​en.wikipedia.org: PCI Express - Wikipedia
12:04:37 <geist> yeah there's this new optane-in-ddr-slot stuff that's i think already showing up in newer motherboards
12:04:44 <graphitemaster> DIMM.2 slot
12:04:45 <graphitemaster> it's called
12:04:50 <geist> but i dunno if intel has yet made one of those critters. so far all the optanes are in NVMe
12:05:21 <graphitemaster> here it is http://i.imgur.com/c0J7YOd.jpg
12:05:25 <graphitemaster> my board has it, I use it
12:05:38 <graphitemaster> you slot in the dimm.2 riser card, and it has FOUR m.2s on it
12:05:46 <graphitemaster> each at 32Gb/s
12:05:51 <geist> cute. can you put regular memory in it or are they mostly just ecycling the connector?
12:06:05 <graphitemaster> geist, the slot if offset from regular DDR3, so no
12:06:08 <graphitemaster> s/if/is/
12:06:12 <graphitemaster> and the board is DDR4 obv
12:06:15 <sortie> <__pycache__> int main(int argc, char **argv) { POSIX_API(5); /* or something like that */ ...initialize... some_posix_function(abc, def); .... return 0; }
12:06:16 <graphitemaster> so that's different
12:06:21 <graphitemaster> just looks like they're reusing the slot
12:06:21 <geist> ah that's true
12:06:34 <sortie> Surely you mean #define _POSIX_C_SOURCE 200809L
12:06:34 <geist> makes sense. inventing a new socket is probably very non free
12:06:57 --- quit: uvgroovy (Quit: uvgroovy)
12:07:05 <graphitemaster> geist, actually I'm wrong, it's _exactly_ DDR3 slot, it's not offset for the middle bit. The only difference is that strange Dimm.2 metal bar across it on the side
12:07:12 <graphitemaster> that prevents you from slotting in DDR3 there
12:07:19 <graphitemaster> however the riser card will slot into a DDR3 slot :P
12:07:27 <geist> i do have to say this recent sploit stuff has set the bit in my brain that i should find an excuse to buy a THREADRIPPER
12:07:48 <graphitemaster> idk what would happen if you installed m.2 into a DDR3 tho.
12:07:54 <graphitemaster> like if that would damage a board
12:08:03 <rain1> is threadripper vulnerable or not?
12:08:12 <graphitemaster> not to meltdown
12:08:14 <sham1> Vulnerable to what
12:08:15 <geist> not to variant 3 (meltdown)
12:08:18 <graphitemaster> but everyone is effected to spectre
12:08:23 <geist> right
12:08:35 <sham1> Yeah, spectre attacks are pretty universal
12:08:46 <graphitemaster> there is an easy mitigation to spectre tho.
12:08:59 <graphitemaster> stop using if statements to prevent out of bounds accesses
12:09:03 <graphitemaster> use saturating/masking arithmetic
12:09:07 <graphitemaster> :P
12:09:08 --- quit: eivarv (Quit: Sleep)
12:09:21 <rain1> i like the sound of that
12:09:29 <graphitemaster> instead of: if(index < size) memory[index]; do if(index < size) memory[index % size]
12:09:42 <graphitemaster> speculative execution will hit still
12:09:49 <rain1> would be worried a compiler might remove the % size
12:09:53 <graphitemaster> but not leak anything
12:10:04 <geist> doug16k: in case you're interested, we've been tracking all the nvmes we've seen in the wild: https://docs.google.com/spreadsheets/d/e/2PACX-1vTWOIQV6fTaGmamFelbHBY4xC8K3GroCI5jRcAb-up-EPuoHyxO7zG8oiDHi0VYoIEF-s5GEvRcBLfn/pubhtml
12:10:06 <bslsk05> ​docs.google.com: NVME Device Info
12:10:13 <graphitemaster> if you pick power of two sizes for all array sizes, do memory[index & ( size - 1 ) ]
12:10:31 <izabera> the actual fix for spectre/meltdown/future attacks is to run cloud stuff in emulators like bochs instead of kvm
12:10:51 <graphitemaster> someone already found an escape from hypervisor exploit with spectre for qemu/kvm
12:10:59 <sham1> Uuuuh
12:11:05 <sham1> That's actually not good
12:11:06 <geist> was actually thinking that the KPTI thing might hurt something like qemu/kvm pretty bad. or really anything that involves a relatively high number of syscalls that kvm requires
12:11:06 <graphitemaster> to leak the memory
12:11:50 <sham1> But when it comes to spectre and meltdown, I just love this media-induced panic
12:11:56 <sortie> __pycache__: Why does your whois information say "annoying" and "Now with 100% more annoying." I kinda consider this a confession of trolling.
12:12:07 <geist> doug16k: this is the lovely thing about working at a company that gives you a company card. you wanna test hardware? go buy it
12:12:08 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
12:12:34 <sortie> geist: Expensing is the best invention since the credit card
12:12:38 <graphitemaster> I like my idea. The compiler should just have an option where, it just masks all memory references with the masked value if it sees a branch that trys to prevent out of bounds
12:12:43 <sortie> <3
12:12:51 <graphitemaster> that would completely mitigate spectre attacks
12:12:58 <graphitemaster> if you had 100% coverage from the compiler
12:13:16 <graphitemaster> and it wouldn't even cost that much compared to all the insane things I'm seeing
12:13:16 <geist> i havent looked into it, but apparently both gcc and clang/llvm are going to get some sort of retpoline mitigation
12:13:19 <sortie> Traveling on company dime is great. I don't have to spend any money and I can live off the land (raiding MKs and cafés).
12:13:22 <geist> i am curious what that's going to look like
12:13:28 <graphitemaster> geist, oh have you not seen?
12:13:32 <graphitemaster> geist, can I link you sadness
12:13:42 <geist> sortie: yeah, and the google embassies in various countries are fantastic
12:13:53 <geist> graphitemaster: does it involve a dead puppy?
12:14:13 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
12:14:22 <geist> actually for some reason the ice cream cone on the ground has always been one of the saddest classes of sad pictures for me, somehow
12:14:25 <graphitemaster> geist, it involves dead caches
12:14:39 <graphitemaster> I need to find it
12:14:40 <geist> or the kid losing the balloon that floats in the sky
12:14:55 <sham1> geist: well, it's wasted ice cream. Who would be happy in that situation
12:15:02 <geist> (i lost a balloon once when i was like 4 and it traumatized me)
12:15:23 <geist> sham1: exactly! it's less ecause i emphathize with whoever dropped it, and more that i'm sad for the ice cream
12:15:56 <sortie> geist: You joke, yet our revenue is only exceeded by 70 countries.
12:15:59 <geist> probably why i have too many computers, i have a default bias towards anthropomorphizing inantimate objects
12:16:24 <geist> i have to actually fight the urge to name things and/or feel sorry for throwing out functional hardware
12:16:33 <sortie> Our local embassy^Woffice is great though
12:16:55 <geist> sortie: yeah i need to find an excuse to visit your office. wish you'd just go ahead and join the team, then i can visit
12:17:06 <geist> :)
12:17:12 <sortie> :)
12:17:14 <graphitemaster> damn twitter is just a huge mess, it's hard to find stuff from a few days ago
12:17:24 <sortie> geist: Well we have a Flutter department?
12:17:34 <geist> yeah there ya go!
12:17:47 <geist> if fuchsia is a juggernaut then it'll totes put Dart on the map, mang.
12:17:55 <sortie> I helped a coworker get zircon working on her Nuc
12:18:06 <geist> oh sorry there. it's pretty rough still
12:18:11 --- quit: uvgroovy (Client Quit)
12:18:27 <sortie> Turns out she had it all figured out, just typoed a 'x'. Your stuff worked :)
12:18:39 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-cspcwsxnoicheqyr) joined #osdev
12:18:43 <geist> we have some new automated paver thing that blasts a new partition table and whatnot
12:18:48 <sortie> geist: Yeah cool to have dart used by flutter used by fuchsia
12:18:57 --- quit: Asu (Quit: Konversation terminated!)
12:19:02 <geist> some of this is because we're just switching the low level disk format over to a new partitioning/lvm style scheme
12:19:22 <geist> + a new read only, merkel-tree validated object fs or something
12:19:37 <geist> so needs to carve all that out
12:20:47 <sortie> Making a new FS?
12:21:09 <geist> i think the idea is most apps and whatnot are functionally read only blobs of code/library/data
12:21:37 <geist> so i think the idea is that you'd generally download blobs that are stored as content addressible chunks of data, validated with some sort of merkel tree thing
12:22:01 <geist> instead of sitting that on top of a traditional fs, it sits on top of a lower level LVM style thing that can carve out the disk into a bunch of variable sized chunks
12:22:06 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
12:22:16 <geist> that's called FVM i think
12:23:15 <geist> there's still a traditional looking unixy fs on the side, but that's mostly for unixy style command line stuff, and/or where the core system lives
12:23:42 <graphitemaster> geist, well, because there has been so much media on spectre and meltdown I will never find the sadness I wanted to show you.
12:23:59 <geist> ah well, probably dont need any more sadness right now
12:24:15 <geist> i started to play The Last of Us last night, but damn that game is *intense*
12:24:24 <geist> i had to stop after a bit, it was too much for my fragile psyche
12:24:30 <sham1> Dem feels
12:24:39 <geist> holy shit it starts off deep in feels land
12:24:40 <graphitemaster> geist, if I manage to randomly occur across it again I'll link you.
12:25:00 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
12:28:33 <geist> speaking of FSes, now that apple has switched to a proper snapshotting fs it has the downside of disk space not getting freed when you delete it
12:29:01 <geist> time machine basically sits around and locally snapshots the fs every hour or so, then when it sees a backup disk it more or less plays back the snapshots to the disk. that's cool
12:29:16 --- join: bpye_ (~quassel@unaffiliated/bpye) joined #osdev
12:29:25 <geist> but it also means if you delete something locally your disk doesn't really get freed until the next time it backups, and then only if it decides to consume the snapshot(s) hat hold the file
12:29:30 <geist> kind of annoying
12:29:32 <graphitemaster> I'm surprised Apple hasn't moved to full cloud storage snap shots yet.
12:30:01 --- join: jpo_ (~jpo@unaffiliated/jpo) joined #osdev
12:33:49 --- quit: EvilJStoker (Killed (wolfe.freenode.net (Nickname regained by services)))
12:33:58 --- join: hunterlabs_ (Elite20801@gateway/shell/elitebnc/x-fglnkmwrqgvxgyqt) joined #osdev
12:34:04 --- join: EvilJStoker (jstoker@unaffiliated/jstoker) joined #osdev
12:34:20 --- join: andrewrk_ (~andrewrk@67.205.169.64) joined #osdev
12:34:50 --- join: dude1231- (None@gateway/shell/elitebnc/x-tysfgezgfdicfads) joined #osdev
12:35:04 --- join: unixpickle (~alex@2601:645:8103:60b6:bde7:a99b:3a70:439b) joined #osdev
12:35:26 --- quit: dude12312414 (*.net *.split)
12:35:26 --- quit: raph_ael (*.net *.split)
12:35:26 --- quit: glfernando (*.net *.split)
12:35:26 --- quit: hunterlabs (*.net *.split)
12:35:26 --- quit: swetland (*.net *.split)
12:35:28 --- quit: andrewrk (*.net *.split)
12:35:28 --- quit: lecx (*.net *.split)
12:35:28 --- quit: bpye (*.net *.split)
12:35:28 --- quit: jpo (*.net *.split)
12:35:31 --- nick: andrewrk_ -> andrewrk
12:36:57 --- quit: eivarv (Quit: Sleep)
12:37:58 --- quit: blueglass (Ping timeout: 260 seconds)
12:38:14 <atrapado_> hi, I have two questions about spinlocks. the first one is: can a spinlock be normally operated from two or several virtual addresses that point to the same physical address?
12:38:50 <sortie> I believe so
12:39:03 <sortie> L1 caching, IIRC, happens of physical addresses
12:39:08 --- quit: heddwch (Ping timeout: 260 seconds)
12:39:23 <sortie> Even if it didn't, if another CPU needed the cache line, it would invalidate it properly on the other CPU
12:39:28 <geist> sortie: not exactly, but they practically speaking are
12:39:35 <geist> atrapado_: yes
12:39:42 <sortie> I wouldn't know for sure. geist knows more than me.
12:39:58 <geist> L1s are usually virtually indexed, but using various trickery act as a PIPT cache
12:40:18 --- join: heddwch (heddwch@2604:180:1:10e::3e89) joined #osdev
12:40:21 <geist> but your second statement is what really happens
12:40:29 --- join: blueglass (~a@104.236.67.153) joined #osdev
12:40:37 <geist> L1 caches are AFAIK always exclusive if you write to it
12:40:49 <geist> exclusive to other L1s
12:41:17 <corecode> ya you need to be careful not to thrash the cache
12:41:55 <corecode> or rather, bounce the cache line around
12:41:59 <corecode> which is not trashing really
12:42:03 <_mjg> the question is a little bit worrying, are you implementing something for synchroisation across processes?
12:42:15 <corecode> why is it worrying
12:42:44 <atrapado_> the second one is: is there any advantage or disadvantage of using small or big variables for holding spinlocks (1/2/4/8 bytes), apart from the storage usage?
12:42:44 <geist> linux actually has something exactly like this. futexes work across process boundaries
12:42:52 <_mjg> normally you don't want to end up with spinlocks in a preemptable environment
12:42:52 <sortie> geist: Yeah I just learned that detail Friday when a co-worker explained caching
12:42:54 <geist> by using precisely this mechanism: the atomic variable is mapped multiple places
12:43:09 <corecode> atrapado_: use natural size
12:43:15 <corecode> i.e. int
12:43:15 <geist> sortie: yeah look into MOESI i believe. it's a fairly standard cache algorithm
12:43:29 <corecode> maybe pad & align to cache line size
12:43:51 <geist> right, spinning in user space on a variable is almost never what you want to do
12:44:04 <atrapado_> ok so in amd64 I would use 8 bytes?
12:44:05 <geist> spinning with some sort of backoff is useful though
12:44:54 <atrapado_> well the case was that the spinlock would reside in the process address space, protected from the user, but would be used from the kernel
12:45:54 <_mjg> what is it going to be used for?
12:45:55 <corecode> why in the process address space?
12:46:06 <corecode> saving kernel memory space?
12:46:09 <geist> that sounds like a Bad Idea, though functionally futexes work on the same principle
12:46:16 <geist> except they're not spinning, it's just an atomic
12:46:31 --- join: Retr0id (~Retr0id@unaffiliated/retr0id) joined #osdev
12:47:00 <atrapado_> well, because of simplicity of memory allocation, I allocate them on the process address space
12:47:09 <geist> yeah that's a Bad Idea
12:47:11 <atrapado_> but without the user bit set
12:47:22 <_mjg> ye sounds misdesigned man
12:47:26 <graphitemaster> spinning in user space on a variable is sometimes all you can do tho if you need precisely timed locking behavior for realtime reasons.
12:47:27 <_mjg> what do you protect with them?
12:47:30 <corecode> geist: why?
12:47:46 <atrapado_> it is not accesible to user space
12:47:49 <geist> if anything just because it's a big source of errors
12:47:51 <graphitemaster> since waited locks are subjected to timing granularity of the OS.
12:48:03 <geist> now your range checks for the kernel are much more complicated
12:48:09 <_mjg> why can't you place the lock e.g. in struct task or whatever you have
12:48:15 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
12:48:18 <geist> whereas if you hard line the idea that if it'sin kernel space it's kernel code, and if its user its user
12:48:26 <corecode> why don't you let people do what they want?
12:48:28 <geist> the permission checks as you validate pointers coming from user space are muc much simpler
12:48:35 <corecode> don't tell them their ideas are stupid
12:48:36 <atrapado_> because the number of locks might grow and would not fit in a static location
12:48:44 <geist> if you have to validate it per page, then your permission checks are far more complicated
12:48:57 <atrapado_> they are not coming from userspace
12:49:14 <graphitemaster> never hold locks across userspace and kernel
12:49:16 <_mjg> do you have a functional memory alocator?
12:49:17 <geist> sure tey are. do you have syscalls that in any way take pointers to user space?
12:49:19 <atrapado_> the are only used by the kernel
12:49:24 <corecode> atrapado_: so what people are concerned about is that now you need to make sure that whoever accesses this address (while in the kernel) actually has the right address space mapped
12:50:02 <geist> right... so, if you're 64bit you can probably mitigate tis somewhat by statically declaring that all kernel allocations in user space are always restricted to a known range of user space
12:50:03 <_mjg> you are going to need one anyway and worst case you can allloc cache-aligned spinlocks from that
12:50:05 <geist> and never the two shall mi
12:50:09 <corecode> usually the kernel assumes that all addresses are fair game
12:50:17 <geist> mix, now the range check is not so bad
12:50:23 <atrapado_> yes, I do, they are on a fixed location
12:50:38 <corecode> atrapado_: what do you use these locks for?
12:50:39 <atrapado_> well, growing, but starts at a fixed location
12:50:51 <geist> though you still have to deal with buffer overflows from valid user buffers, which is usually easier if you have a split user/kernel, double so if it has a architecturally mandated gap in it, like x86-64 has
12:50:57 --- quit: Halofreak1990 (Ping timeout: 268 seconds)
12:51:37 --- quit: navidr (Quit: Connection closed for inactivity)
12:51:40 <geist> from my point of view it's far less error prone to just consider the two address spaces completely separate permission wise
12:51:53 <geist> also keep in mind that some architectures mandate this in hardware (MIPS comes to mind)
12:52:01 <atrapado_> well, it is in the lower half, but has no user bit set
12:52:02 <_mjg> ye. i don't think you are solving an actual problem this approach
12:52:20 <corecode> i'm interested in the approach
12:52:24 <geist> which seems silly but in retrospect is a good idea, because stuff like meltdown gets nerfed before it gets started, because having the top bit set explicitly makes the address kernel only
12:52:29 <_mjg> and you are adding cruft: now you have to exclude the areaa for your copy_from/copy_to
12:52:32 <atrapado_> corecode, I was thinking of using for ipc
12:52:49 <geist> atrapado_: are you thinkinf o having say a per thread bounce buffer for the kernel?
12:52:50 <corecode> atrapado_: so the locks would be shared between processes?
12:53:01 <graphitemaster> geist, does fuchsia hold locks across userspace/kernel space?
12:53:12 <geist> a way to mitigate that is to just double map it. map one in user space and another copy of it in kernel (if it isn't already)
12:53:17 <atrapado_> no, but I would need 2 locks for communicating between two processes
12:53:27 <geist> that way you can avoid a user copy in/out which are intrinsically more expensive than just directly accessing it in user space
12:53:27 <corecode> atrapado_: explain?
12:53:33 <geist> graphitemaster: no way
12:53:38 --- join: _sfiguser (~sfigguser@5.102.3.248) joined #osdev
12:53:50 <_mjg> if only the kernel takes the locks, there is no benefit from adding them to that area
12:54:13 <graphitemaster> geist, does fuchsia hold a kernel lock that can be initiatied by userspace?
12:54:29 <atrapado_> well, the processes have a number of ipc channels and e.g. two processes could be closing the same channel at the same time
12:54:31 <geist> well, as part of internal operation on kernel data structures, sure
12:54:52 <graphitemaster> geist, I mean more like, can it acquire a lock initiated from userspace but fail to unlock when entering back into userspace
12:54:52 <geist> it eds up grabbing an internal mutex in the kernel itself, which may involved rescheduling, etc
12:54:58 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:55:00 <geist> absolutely not
12:55:07 <graphitemaster> so all locks are 1:1
12:55:07 <atrapado_> and I would prefer not to have only one spinlock for all
12:55:09 <geist> that would be a SRS ERROR
12:55:09 <_mjg> atrapado_: normally the lock would be embedded in whatever struct describes the channel
12:55:26 <_mjg> atrapado_: so only channel users interfere with each other
12:55:31 <atrapado_> I do, _mjg
12:56:17 <geist> graphitemaster: right
12:56:33 <graphitemaster> geist, surprsingly, this is something Linux cannot gurantee.
12:56:34 <geist> except of course futexes, but those are a special case of kernel assist for a user space lock
12:56:51 <atrapado_> but for not having to allocate memory in the kernel, I allocate them in the process address space, but protected from the user
12:56:59 <graphitemaster> It's possible for a crashed userspace application to leak a kernel lock and cause a resource error.
12:57:01 <geist> graphitemaster: in fact a TODO iteam i have that i hope i can get someone to work on is add better mutex lock checking, probably via tracking all the held mutexes in a thread
12:57:01 <atrapado_> for simplicity of allocation
12:57:18 <geist> and in that case we can actually make a assert that no mutexes are held as the thread exits kernel space
12:57:37 <graphitemaster> This is probably something microkernels are just better at, less complexity in the kernel that can cause these issues.
12:57:39 <geist> but it hasn't thus far been a big problem. mostly because we're fairly religious about using RAII lock guards and whatnot
12:57:55 <geist> and then there's that. mthere's not a lot large pile of driver code, which is usually the big offender of this
12:58:08 <graphitemaster> drivers should not hold locks imho.
12:58:23 <geist> yeah but internally they generally need at least spinlocks to protect themselves
12:58:38 <geist> and many times they have some sor tof queing mechanism that may be nicer to use a mutex for
12:59:40 <graphitemaster> geist, I've been seriously looking at making a microkernel of my own because I _really_ want to test my services based idea but it's just a lot of fucking work and _ugh_
12:59:51 <_mjg> linux had cases where threads were "legitimately" exiting with semaphores held
12:59:53 <graphitemaster> it will be super slow
12:59:58 <_mjg> i mean leaving the kernel
13:00:02 <geist> yeah totes. it seems deceptively easy but then you have to actually think about design up front
13:00:05 <geist> and then that's hard
13:00:15 <graphitemaster> I don't care about performance as much as I care about security
13:00:33 <_mjg> fortunately that was root-only code (nfs)
13:00:42 <geist> that's been a fair amount of what we're doing in fuchsia. i think there's a space now since cpus are so generally fast to have a relatively slower but more secure by design OS
13:01:12 <geist> doubleplus so if you're not designing to compete directly with things that intrinsically use a lot of kernel syscalls (ie, POSIXY file io + lots and lots of forks)
13:01:25 <geist> which monolithic systems like linux are always going to own on
13:02:03 <geist> whereas i think back in the 90s or so when ukernels were all the rage it was somewhat harder to justify it when the base overhead of the system was more percentage wise a piece of the total system
13:02:24 <graphitemaster> my block design is "hypervisor microkernel", the owner of all, it runs only "service kernel" (on each core), then "services" run on the service kernels (service kernels communicate tasks for SMP to the hypervisor), there's an application service that runs applications, no libraries at all. Everything communicates with services using some shared key security mechanism on a lockless SPSC queue with a nice API (like go channels)
13:02:30 <geist> and as security gets more and more important, i think there's a space to occupy there
13:02:45 <graphitemaster> that's all I want to build
13:02:51 <geist> that's where it gets interesting. hypervisors and microkernels kind of blur together if you consuder the hyeprvisor to just be another layer
13:03:06 <geist> ARM even basically codifies that into their design, since they treat the hypervisor layer as just another ring of supervisor
13:03:21 <geist> vs x86s totally weirdass (when you thinl about it) side step in vmenter/vmexit
13:03:23 <graphitemaster> mine is more like a true software stack tho.
13:03:29 <graphitemaster> not really a hardware level concept
13:03:36 <geist> fair
13:03:42 <graphitemaster> I just want to codify the access to pages at the hypervisor level
13:03:53 <graphitemaster> and then let service kernel be the only thing that can map memory around and what not
13:04:10 <graphitemaster> so nothing else can run on hypervisor level
13:04:29 <corecode> why do you call it hypervisor?
13:04:32 <graphitemaster> then everything is secured not by pages of memory defined by the MMU
13:04:34 <corecode> isn't that just a normal supervisor?
13:04:42 <graphitemaster> but rather channels defined by the hypervisor given to the services
13:04:43 <geist> my other thought was since x86 is so popular it traditionally worked against the initial ukernel push
13:04:59 <geist> since it's the most unsuitable architecture you can design for that sort of thing (more so back in the 90s)
13:05:12 <geist> so it acted as backpressure at the time against that sort of design
13:05:14 <graphitemaster> corecode, well my design is about eliminating the need for an MMU, for system calls, and the whole ring level translation at the user-stage.
13:05:21 <graphitemaster> because service kernel is basically "user space"
13:05:28 <graphitemaster> hypervisor is ring0
13:05:36 --- quit: Youmu (Quit: Connection closed for inactivity)
13:05:38 <graphitemaster> and then actual applications are even more locked down
13:05:47 <geist> graphitemaster: but in some sense you're building a standard hard core ukernel at that point
13:05:59 <geist> ie, the service that acts as the subsystem that processes are using is a super server
13:06:04 <corecode> so supervisor
13:06:24 <geist> which is fine of course. i kind of wish we went more that direction in fuchsia, but we had constraints to operate in
13:06:41 <graphitemaster> geist, except that service kernel is the only "application" the hypervisor is allowed to run, and the service kernel is basically like traditional "root" from the eprspective of UNIX, so it can ask the kernel how to map memory and what not.
13:07:08 <graphitemaster> whereas application service running on service kernel is more locked down.
13:07:10 <corecode> graphitemaster: did you read the barrelfish papers?
13:07:38 --- join: raph_ael (~raphael@2a00:dcc0:dead:a066:216:3cff:feae:868a) joined #osdev
13:07:38 --- join: swetland (sid155178@gateway/web/irccloud.com/x-cvkclstpyjjrssjv) joined #osdev
13:07:38 --- join: lecx (lex@yuuh.pw) joined #osdev
13:09:05 --- quit: bm371613 (Quit: Konversation terminated!)
13:09:33 <graphitemaster> corecode, yes
13:10:02 <corecode> so why is -uintvar/(double)uintvar2 different from -(uintvar/(double)uintvar2)
13:10:03 <corecode> wtf C
13:10:06 <corecode> what are you doing
13:11:01 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:13:17 <geist> how different does it end up being, i can definitely see it differing in when the negation is applied
13:13:48 <graphitemaster> geist, the core of the idea is that the super server can run and be the only thing that has to go through the traditional "route" of kspace/uspace context switching :P
13:13:58 <graphitemaster> so it should technically be faster
13:15:02 <doug16k> corecode, if you negate an unsigned int it becomes an insanely large number
13:15:41 <doug16k> if you do the divide, THEN negate, it works as you would expect
13:16:32 <geist> oh oh it's uint. yeah that totally makes sense
13:16:49 <geist> if it was an int, it might only make some sort of rounding difference maybe
13:16:49 <doug16k> -1U == 0xFFFFFFFFU -> 4 billion-ish / uintvar2
13:17:31 <doug16k> C is doing exactly what you said :D
13:18:11 <geist> *realy* the idea that you can negate an unsigned is fairly weird, and thats probably the real problem
13:18:18 <geist> seems like you could really consider that an error in the first place
13:18:36 <clever> that reminds me of a bug in an online game i played, they used signed 32bit ints for resources in the game, and it would overflow past 2^31, causing all of the resource to be lost
13:18:44 <geist> as it is i actually dont know precisely what happens off hand if you negated say a uint16 (on a machinr where int == 32bit)
13:18:52 <geist> it probably promotes the result to a signed int
13:18:54 <clever> the devs "fixed" it, by coding it to hard-cap at exactly 2 billion, if you went over 2 billion
13:18:56 <corecode> i really should use fixed point support in gcc
13:19:02 <corecode> doing this manually just adds so many mistakes
13:19:05 <clever> but only if you land between 2 billion and 2^31
13:19:11 <doug16k> geist, yeah, I think it promotes to signed int
13:19:16 <geist> which is general why i avoid nowadays using < uint32 for any math
13:19:17 <clever> if you manage to exeed 2^31 in a single turn of the game, you still reset to 0
13:19:18 <sortie> clever: Clever
13:19:37 <geist> i only really use uint16s if i need to match hardware or store something tightly, but i fyou start doing math on it it gets Complicated, because of the int promotion stuff
13:19:47 <doug16k> my answer to "wtf signed?" is, "it fits"
13:20:05 --- quit: elderK (Quit: Connection closed for inactivity)
13:20:07 <geist> so even in the case of - a uint, at best it's inconsistent with say negating a ushort
13:20:26 <geist> since uint gets promoted to a uint, vs doing what would generally be consistent and promote it to a signed next-larger type
13:20:30 <geist> like a signed long or long long
13:20:36 <clever> ive also had nasty bugs in my router
13:20:47 <clever> the NIC in the router uses an unsigned 32bit traffic counter
13:21:04 <clever> the html UI, uses a 32bit SIGNED number when printing it to the html
13:21:20 <geist> i read some article by stroustrup and this was one of the reasons he actually advocates using more signed types
13:21:32 <geist> even for things like length, because you dont get into weird promotion rules
13:21:52 <geist> and it allows the compiler to optimize for wrap because it technically doens't exist and thus gives the compiler more freedom
13:22:04 <clever> the result of the above, is that the web interface stops counting traffic at 2^31 bytes
13:22:08 <geist> downside is of course you now have to check for that stuff, but then now you're explicitly doing it, instead of it being some hidden nonsense
13:22:12 <clever> and just hangs until it rolls over 2^32
13:22:19 <clever> then it resets to 0 like it should have
13:22:54 <geist> really fundamentally this low level type and promotion rules and wrap and whatnot is probably my #1 beef with C/C++
13:22:55 --- quit: Halofreak1990 (Ping timeout: 264 seconds)
13:23:07 <geist> you gotta respect all those languages that just have infinite precision everything
13:23:19 <geist> though clearly that makes it much harder for low level programming, etc
13:23:51 <doug16k> I find it mostly does the right thing, and when it doesn't, it's because I told it to do it wrong
13:24:05 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
13:24:06 <doug16k> I like it when it does what I said, even if it is surprising
13:24:09 <jjuran> An older version of an app that reads NFC transit cards didn’t take into account that the balance on the card was a signed number, and could go negative. So it might report $655.26, for example.
13:24:53 --- quit: freakazoid0223 (Ping timeout: 246 seconds)
13:25:14 <clever> jjuran: if the balance is on the card, you already screwed up
13:25:39 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
13:25:45 <jjuran> clever: The card reports what the balance is. I don’t know what the source is.
13:26:21 <clever> but i could just edit that value directly, or make a fake NFC card
13:26:23 <jjuran> Anyway, BART stopped letting you exit with even a minor deficit, so it ceased to be an issue.
13:26:51 <jjuran> clever: Right, you could fool the phone into reporting the wrong balance.
13:27:08 <doug16k> it's like the word "queue". I think the spelling is ridiculous, but I spell it that way :D
13:27:44 <clever> jjuran: detecting negatives is also why the game i previously mentioned threw away half its range to use a signed int
13:27:55 <clever> jjuran: if you go negative, it gives you a penalty and sets you to 0
13:28:17 <clever> but if you do too well, you roll over to massive negative, then it gives you a penalty and voids all your resources
13:29:05 <jjuran> clever: Presumably, BART logs the transactions and can discover discrepancies. If you forge a new balance, they’d find out, and the next time, they’d catch you.
13:29:17 <clever> one would hope
13:31:19 --- quit: caen23 (Ping timeout: 264 seconds)
13:32:57 <jjuran> Another factor is that their losses are limited. Worst case, you defraud them of a $15 fare or such on trains that were running anyway. Stolen credit cards are much worse.
13:33:32 --- join: svk (~svk@p2003006A65481000B46E5035EE6F422E.dip0.t-ipconnect.de) joined #osdev
13:33:55 <geist> jjuran: you're talking about the same BART i'm thinking of?
13:34:06 <jjuran> In SFBA
13:34:13 <geist> reminds me, i have a pile of old bart cards i should bring to MTV next week and hand out
13:34:16 --- quit: darklink (Ping timeout: 255 seconds)
13:34:24 <geist> since i'm never going to use them and i think they hold their value forever
13:36:15 --- join: darklink (~darklink@unaffiliated/darklink) joined #osdev
13:37:00 <sortie> <geist> jjuran: you're talking about the same BART i'm thinking of? ← https://media.giphy.com/media/l4FGjhtxlrxuLBgkw/giphy.gif
13:38:48 --- quit: m_t (Quit: Leaving)
13:39:51 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:40:33 <graphitemaster> sortie, love that parallax
13:52:36 --- quit: tavish (Quit: Leaving)
13:57:43 --- quit: glauxosdever (Quit: leaving)
14:02:55 --- quit: eivarv (Quit: Sleep)
14:03:41 --- quit: meowrobot (Quit: let us connect our intestines and mutually digest)
14:04:23 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
14:05:11 --- quit: _sfiguser (Remote host closed the connection)
14:05:17 --- join: meowrobot (~katgirl@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
14:08:14 --- quit: meowrobot (Client Quit)
14:09:44 --- quit: sprocklem (Ping timeout: 265 seconds)
14:09:49 --- join: meowrobot (~katgirl@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
14:11:39 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
14:14:04 <graphitemaster> <geist> i read some article by stroustrup and this was one of the reasons he actually advocates using more signed types
14:14:04 <graphitemaster> <geist> even for things like length, because you dont get into weird promotion rules
14:14:05 <graphitemaster> <geist> and it allows the compiler to optimize for wrap because it technically doens't exist and thus gives the compiler more freedom
14:14:19 <graphitemaster> except signed integer overflow is implementation defined
14:14:50 <graphitemaster> signed types are one of those things that I try hard to stay away from in my code.
14:15:28 <_mjg> -fwrapv
14:15:50 <_mjg> signed types make it easier to have a security bug when you fucked up
14:16:38 <graphitemaster> unsigned types have problems too
14:16:45 <_mjg> what does not
14:16:53 <graphitemaster> but I'm of the view that unsigned is certainly a much easier thing to learn and teach
14:17:07 --- quit: meowrobot (Quit: let us connect our intestines and mutually digest)
14:17:37 <graphitemaster> because overflow and underflow are well defined to wrap.
14:17:40 --- quit: Belxjander (Ping timeout: 252 seconds)
14:17:56 <graphitemaster> and you avoid all the ugly problems of having to explain ones/twos complement and implementation behavior
14:18:01 <_mjg> so overflows are a sign you fucked up anyway: data is not validated
14:18:21 <_mjg> ignoring ofc cases where you know this is fine
14:18:42 <_mjg> part of why i think things like mallocarray are garbage
14:19:00 <_mjg> (bringing this up since it got recently committed to freebsd, brought over from openbsd)
14:19:01 <graphitemaster> and since unsigned is allowed to overflow/underflow, it's easier to write code that checks for underflow/overflow of operations
14:19:10 <graphitemaster> without worrying the compiler will eliminate your check.
14:19:34 <_mjg> there was a magic "func" to check
14:19:38 <_mjg> i don't remember the name
14:19:48 <graphitemaster> magic is hard to teach and learn
14:19:52 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:20:07 <graphitemaster> Google's coding style suggests to avoid unsigned integers tho. They want everyone to use signed everywhere for some reason.
14:20:07 <geist> graphitemaster: yeah there were good reasons though, mostly in that since folks frequently *dont* check for unsigned wrap
14:20:10 <_mjg> i mean you would if (this_multiplicated_would_overflow(foo, bar)) { scratch_it(); }
14:20:24 <geist> it's easier to mess up in some inner math loop and then expose a wrapped variable
14:20:32 <geist> whereas if it's signed it'll probably go negative and then you can just check
14:20:44 <geist> the canonical example is some sort of length arg
14:20:58 <geist> foo(void *, unsigned len);
14:21:03 <_mjg> there was a funny vuln in solaris
14:21:10 <geist> then some doofus calls it with foo(ptr, base + len);
14:21:12 <_mjg> they had c routines tking size_t or something
14:21:24 <geist> if that math wraps then foo has no way to know if it's dumb and fail
14:21:26 <_mjg> but they would call hand-rolled assembly which was doing signed comparison
14:21:27 <graphitemaster> geist, except if you check for negative, the compiler is allowed to (and most certainly will) remove it because if your code actually causes it to go negative, it's depending on implementation defined behavior unless you use the appropriate compiler flags.
14:21:46 <_mjg> not expecting < 0
14:22:11 <graphitemaster> geist, yeah unsigned makes it easier to forget to check, I'll give you that one.
14:22:34 <graphitemaster> But signed does not really solve the problem, it just makes you think about it and then incorrectly check for the overflow and have the compiler silently remove it from under you.
14:22:37 <geist> but you're right, the entire post was predicated that signes with wrap the same way, and end up negative
14:23:06 <geist> and modern compilers (perhaps since he wrote that) are starting to really exploit the fact that they can go into undefined land
14:23:18 <geist> perhaps it was more practical Back Then, like when the stdc++ library was defined
14:23:27 <geist> and generally uses more signeds than you'd think it should
14:23:29 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-jstiwkxaxaqpqeer) joined #osdev
14:23:46 <graphitemaster> it's also really dangerous in that signed types can't represent the full range that you can address with and I've seen it become an accidental path in memory accesses and DISK IO with truncation and now you have some arbitrary limit that didn't need to exist
14:24:02 <geist> yah signed off_t is a mistake to me
14:24:21 <geist> or at least using off_t in anything other than lseek. there should have been some sort of filepos_t or whatnot that's unsigned
14:24:38 <_mjg> ssucker_t
14:25:39 <geist> doug16k: if you have a chance, pop into #fuchsia. our nvme dev is having trouble with qemu IRQ for nvme
14:26:13 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-vmtqzxrbfftkdndb) joined #osdev
14:26:25 <graphitemaster> Here's an important distinction to be made. We're all aware of the problems of signed and unsigned. We kind of are pros at this. These codying styles tend to be for people not as famimilar or knolwedgable in these topics. What honestly is the least surprsing behavior to someone learning. Copiler removing code that validates ranges on you, strange overflow/underflow behavior that depends on compiler flags, and architecture. Or
14:26:25 <graphitemaster> something that is defined to overflow/underflow the same everywhere, regardless of flags, and any checks you write for ranges do not get removed by the compiler, regardless of flags?
14:26:39 <graphitemaster> I'm of the view that the latter is better which is why I don't agree with Google's style guide.
14:27:07 <graphitemaster> at least on that very specific topic
14:27:24 --- join: unixpickle (~alex@2601:645:8103:60b6:1925:a1ee:9d1e:9300) joined #osdev
14:27:49 <geist> doug16k: specifically we're having trouble getting classic IRQs working on qemu, which wants MSI-X
14:29:15 <graphitemaster> geist, care to comment https://github.com/graphitemaster/neothyne/blob/master/docs/STYLE.md
14:29:17 <bslsk05> ​github.com: neothyne/STYLE.md at master · graphitemaster/neothyne · GitHub
14:29:24 <graphitemaster> really want professionals opinion on this
14:29:34 <graphitemaster> especially the signed/unsigned size_t, nullpte stuff
14:31:15 <geist> oh man i'm the worst. i'm pretty loose on style and generally roll my eyes when reading style guides
14:31:19 --- quit: Belxjander (Ping timeout: 264 seconds)
14:31:20 <bcos> graphitemaster: Start with a basic spell checker...
14:31:30 --- quit: sprocklem (Ping timeout: 256 seconds)
14:31:31 <graphitemaster> bcos, :(
14:31:37 <bcos> "defintion"
14:31:59 <geist> i generally understand the need for style guides when working on large projects so i have admitted that they're okay
14:32:00 <sortie> typedef bcos definition;
14:32:05 --- quit: plonk (Quit: ZNC - 1.6.0 - http://znc.in)
14:32:12 <geist> but still roll my eyes when it occupies more than 0% of the time of the day thinking/talking about it
14:32:23 <geist> it seems like an endless rathole of time that folks love to dither about
14:32:39 <graphitemaster> geist, ignore the style aspect, just the integer types part https://github.com/graphitemaster/neothyne/blob/master/docs/STYLE.md#integer-types
14:32:41 <bslsk05> ​github.com: neothyne/STYLE.md at master · graphitemaster/neothyne · GitHub
14:32:42 <sortie> The trick is to put style issues all 360 degrees around geist, so there is no place to roll the eyes
14:32:54 <geist> and when you have projects that are super draconian about it, i totally lose interest
14:33:17 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
14:33:27 <sortie> geist: With dart we have the dart formatter, so we just run it on presubmit. Style issues kinda solved.
14:33:30 <geist> it's very similar to me to the way my sail got completely deflated after i slaved away on my labor of love, this 6809 board
14:33:51 <geist> and the absolutely first comment in my facebook post about it, i was so proud, was some fucking nitpick on the README file
14:34:10 <geist> it completely pissed me off, i never returned to the project. completely stamped the feeling in my brain
14:34:16 <sortie> :(
14:34:23 <graphitemaster> geist, I'm sorry.
14:34:42 <geist> style guides feel the same way some time. you really hack on some cool piece of code, really excited abou tit, then you stick it on code review and all anyone has anything to talk about is little nit pick style shit
14:35:24 <geist> but it's low hanging fruit, makes reviewers feel like they are doing their duty. can't fault em
14:35:29 <_mjg> depends how little is little
14:35:35 <geist> it just completely derails it in my mind
14:35:49 <geist> same thing with shit like screenshots for you os. there's 100% a reason why none of my oses have a screenshot
14:35:57 <geist> because folks will just nitpick on some dumb crap about something
14:35:57 <_mjg> say the style mandates you put {}'s at separate lines after if
14:36:00 <sortie> Hmm. I can be nit picky in code reviews. I do it to be helpful and get it as good as possible. I can see how that can be experienced differently by the author. Hmm. I try to also comment that the code is great, I need to do that more.
14:36:04 <_mjg> but you submitted if (foo) {
14:36:07 <_mjg> is that a nitpick?
14:36:12 <graphitemaster> geist, for my own stuff I like having a style guide because I prefer consistency in code and there's a few things that piss me off when I see them because they are wrong (the int for sizes or accessing arrays thing as an example), but when I contribute to anything I always follow _their_ style because being consistent I think is the most important.
14:36:28 <geist> like i said, i totally understand why it's done that way
14:36:40 <geist> it just still completely deflates things sometimes. which is *my* problem, not theirs
14:36:49 <graphitemaster> what pisses me off more is tabs vs spaces debates :P
14:36:55 <rain1> it's hard to get discussion and criticism about the real deeper issues, it's just so easy to make shallower comments about indentation and stuff - low effort
14:36:58 <geist> exactly, at least we put that one to sleep early on
14:36:59 <_mjg> i think if the code is sound it makes sense to point this shit out so that the contributor avoids it for future changes
14:37:15 <_mjg> but for lul bullshit whoever commits the code should just do the work and mention it
14:37:20 <geist> but that is why auto formatters that do a good job mostly solve the problem
14:37:27 <geist> so that has generally made it less of an issue
14:37:39 <graphitemaster> geist, it's just nice saying "look, the style guide is there, read it, if you don't like it don't contribute" insetad of having long winded discussions on IRC
14:37:41 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:37:48 <graphitemaster> having a document that is authority is a win.
14:37:48 <_mjg> by that logic you can submit a patch which is from a performated tree
14:38:07 <geist> _mjg: yeah we have escape clauses for precisely that
14:38:15 <geist> external code that you're importing. do you reformat it? depends
14:38:21 <_mjg> oh man
14:38:22 <_mjg> don't
14:38:23 <geist> mostly on if you intend to keep taking upstream patches or not
14:38:36 <_mjg> imported code is such a pile
14:38:38 <geist> for example for musl for zircon we have hacked the shit out of it, so we reformatted it
14:38:40 <graphitemaster> good luck merging anything if you run your formatting rules on it :P
14:38:52 <_mjg> or diffing against upstream
14:38:58 --- join: glfernando (glfernando@nat/google/x-lmlquymsheybwmgi) joined #osdev
14:39:00 --- quit: epony (Quit: QUIT)
14:39:09 --- join: John___ (~John__@79.97.140.214) joined #osdev
14:39:13 <graphitemaster> you need a maintainer that can backport changes at that point
14:39:26 <graphitemaster> who is familiar with both musl and the zicron fork
14:39:35 <geist> exactly. and we have one. so it's cool
14:39:44 <sortie> :)
14:39:58 <geist> but it's sort of a dick move to the upstream though, except the sort o changes we make are really taking it in a new direction
14:40:17 <geist> for example back when haiku forked newos the first damn thing they did was reformat it, because haiku devs are completely anal about formatting
14:40:29 <geist> and then it made it functionally impossible to merge changes back from their code. i was pretty pissed
14:40:33 <rain1> it sucks how $editor cant just magically learn the formatting of a source file, and then apply that
14:40:59 <geist> nowadays it's probably easier because autoformatting tools, but back then they weren't nearly as good, and the formatting changes they made were far more intrusive (like change snake_case to CamelCase)
14:41:08 <geist> things that automatic tools can't do automatically
14:41:25 <corecode> rain1: mine does
14:41:31 <rain1> give me it
14:41:34 <corecode> emacs
14:41:41 <rain1> please tell me how to set that up
14:41:44 <corecode> sec
14:41:47 <graphitemaster> too bad haiku wasn't anal about making a good OS ;-)
14:41:50 <geist> so it was like trivially switching it to another language to maximize the delta between the source
14:42:10 <geist> but hey, so it goes.
14:42:35 <graphitemaster> some diff tools can ignore whitespace
14:42:44 <_mjg> i still take this over a "freestyle" codebase
14:43:00 <graphitemaster> I have to fight with line endings at work every day
14:43:05 <graphitemaster> I'm getting tired of it
14:43:06 <corecode> rain1: dtrt-indent-mode
14:43:10 <rain1> thanks a lot :)
14:43:18 <graphitemaster> people comitting CRLF
14:43:18 <geist> yeah that made things much better. now that git can ignore whitespace life is a lot simpler
14:43:21 <_mjg> graphitemaster: make a commit hook
14:43:36 <graphitemaster> _mjg, that requires everyone have that hook locally
14:43:46 <_mjg> that can be part of the standard setup
14:43:51 <graphitemaster> well that's not how we work
14:43:54 <_mjg> and you can also check on push
14:43:56 <_mjg> server-side
14:44:05 <graphitemaster> we don't have a developer environment every developer is required to use
14:44:11 <corecode> doesn't git just fix crlf?
14:44:15 <_mjg> well looks like that's the actual problem
14:44:21 <graphitemaster> some people use git for windows, others use msys2, others use plain git on Linux.
14:44:27 --- join: meowrobot (~katgirl@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
14:44:34 <graphitemaster> some use tortisegit, etc, etc.
14:44:43 <corecode> still, push hook on the server
14:44:44 <graphitemaster> that's not really a problem
14:44:48 <jjuran> sortie: Direct link to GIF, please?
14:44:51 <graphitemaster> people like their own environments.
14:45:00 <graphitemaster> being forced into a certain development environment sucks.
14:45:00 <_mjg> there is no problem with your own editor and whatnot
14:45:15 <_mjg> but then they should be forced to configure it with accordance to local rules
14:45:41 <_mjg> by standard setup i predominantly meant a well known procedure to grab the tree
14:45:43 <graphitemaster> push hook on server is a no-no, I don't want some random automated user making commits that only change style
14:45:45 <_mjg> and whatever else
14:45:45 <corecode> that's what i really like about golang
14:45:51 <graphitemaster> or have it modify code...
14:45:54 <corecode> they have a complete formatter
14:46:15 <corecode> server rejects commits where sources change during formatting
14:46:25 <graphitemaster> forcing people into a style sucks too.
14:46:38 <geist> yeah i'm fairly turned off by that and Go
14:46:43 <graphitemaster> as a language decision
14:46:50 <geist> also doesn't allow you to locally violate it and then fix before committing
14:47:02 <_mjg> oh that sucks
14:47:09 <graphitemaster> One of the reasons I also dislike Python.
14:47:11 <geist> otoh i use to rail against -Werror, but we've turned that on for fuchsia and it's annoying but i'm living with it
14:47:20 <graphitemaster> Python is a great language but Pythonic style is really fucking annoying.
14:47:28 <_mjg> -Werror locally = ez
14:47:29 <geist> but it's mostly usable because we fix the compiler version
14:47:45 <corecode> graphitemaster: no, it's great
14:47:45 <geist> whereas for projecs where i can't control the compiler, then -Werror works against you
14:47:48 <_mjg> i meant disabled weror
14:47:49 <corecode> there is never any decision
14:47:55 <corecode> debate*
14:48:12 <_mjg> how often have you seen debates within a team what style to use?
14:48:13 <graphitemaster> One debate that I still see people making is how to do comments in Python
14:48:19 <graphitemaster> is it # or """ """
14:48:19 <corecode> _mjg: so many times
14:48:25 <_mjg> interesting
14:48:35 <_mjg> i see people mostly sticking to something and not saying shit at work
14:48:42 <graphitemaster> _mjg, the day I became lead here we had one whole week of arguing about style.
14:48:43 <geist> as we add more people to the fuchsia project we definitely see it getting brought up again and again
14:48:53 <geist> primarily because zircon deviates from google style guide in a couple places
14:48:56 <graphitemaster> someone also threatened to quit
14:49:00 <graphitemaster> based purely on style
14:49:17 <_mjg> i would quit from an openssl-lilke project
14:49:53 <_mjg> unless the person was insane, presumably that was the last straw
14:49:56 <_mjg> not the actual reaosn]
14:49:56 --- quit: user10032 (Quit: Leaving)
14:50:01 <graphitemaster> openssl-like?
14:50:03 <graphitemaster> what does that mean
14:50:03 <rain1> the hilarious thing about openssl is all the good programmers telling each other not to implement crypto
14:50:08 <_mjg> dude
14:50:10 <rain1> and you are left with.... that..
14:50:25 * graphitemaster has never read OpenSSL code
14:50:40 <geist> i've herad it's a complete nightmare
14:50:42 <rain1> you didn't hear about the libressl fork?
14:50:48 <_mjg> it was popular to shit on it a lot after that memory disclosure vuln
14:51:14 <_mjg> the code is really bad on all programming accounts
14:51:24 <_mjg> no clue about just crypto
14:51:28 <rain1> they were doing shit like putting uninitialized memory into the RNG
14:51:37 <rain1> and implementing their own ad hoc malloc
14:51:43 <_mjg> well ye, unitialized = random, everyone knows
14:51:54 <geist> yeah simplest source of random
14:52:11 <graphitemaster> best source of random is IRC discussions on programming.
14:52:16 <_mjg> esp if 0 or malloc poisin
14:52:22 <geist> best source of time wasting at least
14:52:29 <_mjg> disagree here
14:52:34 <geist> i have been standing up to go do something for the last few hours
14:52:43 <_mjg> reddit and SO lead the charge
14:52:52 <graphitemaster> let's be honest, programming discussions are nothing but bikeshed.
14:52:59 <_mjg> mostly, ye
14:53:14 <graphitemaster> but damn people like showing off their bikes.
14:53:16 <_mjg> did anyone think anyone else will get convinced though?
14:53:41 <graphitemaster> Some languages have the most toxic communities for bikeshedding tho.
14:53:48 <graphitemaster> Haskell and C++ are probably the biggest examples.
14:53:56 <geist> yep, thats part of the whole maturity as a human being
14:54:02 <geist> not getting all fired up over dumb shit
14:54:28 <geist> a lifelong journey for sure
14:54:48 <graphitemaster> it's easy to get fired up over dumb shit, it takes a real person to be humble about dumb shit.
14:55:01 <geist> yep
14:55:24 <graphitemaster> and it takes a cynic to see everything is dumb shit.
14:56:03 <geist> which i guess may or may not be a virtue
14:56:03 <_mjg> i worked with a guy once who just had 0 text editor skills
14:56:04 <jjuran> graphitemaster: Modern compilers (e.g. gcc since 4.0, I think) will memoize the include guards, so pragma once isn’t even more efficient.
14:56:23 <_mjg> everytime he submitted a patch, no matter how short, there were fuckton of whitespcae issues
14:56:32 <geist> i have generally switched to pragma once because of the nonzero times i've seen folks mess up header guards and waste time on it
14:56:35 <_mjg> empty lines before, after, tabs and spaces all around the place
14:56:41 <geist> and then virtually all real compilers support it
14:56:47 <geist> so fuck it, #pragma once, clean
14:56:55 <_mjg> agreed
14:57:17 <_mjg> the ifdef fuckery is something nobody even acknowledges as a problem
14:57:19 <geist> thats one of the things that zircon deviates from the google style guide, and folks bring up fairly regularly internally
14:57:32 <_mjg> i myself mindlessly add them when needed
14:57:48 <_mjg> (the project does not #pragma, so there is that)
14:57:58 <geist> secondly allowing you to not mask part of a header by screwing with the header guard, or testing it from another file i consider a programming error
14:58:04 <geist> so disallowing someone from doing that is a win as well
14:58:16 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
14:58:30 --- quit: John___ (Read error: Connection reset by peer)
14:58:36 <_mjg> my biggest problem with headers is that some people think they should all include all their deps
14:58:42 <_mjg> and others think it's the programmer job
14:58:51 <geist> if using header guards i'd just as soon as it be a bigass random hash, and none of this nonsense about precisely how the header guard is formatted (which is absolutely discussed internally)
14:58:53 <_mjg> to include stuff in *.c in the right order
14:59:02 <geist> move the file, tweak the header guard, etc
14:59:19 <_mjg> the end result is an extreme pollution anyway
14:59:45 <geist> yeha i've seen arguments both ways. i generally do the predeclaration thing if i can avoid it
15:00:02 <geist> there was a fairly well argued reason why you should force the programmer to do it, but i dont remember it now
15:00:26 <_mjg> i don't know any compeling reason to go one way or the other
15:01:03 <graphitemaster> my only rules for headers is that if you rename them to .c/.cpp they should compile as code
15:01:06 <_mjg> oh, this is the worst: people who add comments what is imported from the header
15:01:13 <_mjg> this always gets stale
15:02:00 <geist> yeah, i hate the fact that comments on functions should probably only go in one place or another
15:02:03 <graphitemaster> sometimes you see x-macro headers, those I ignore the rule for
15:02:04 <geist> but i totally get why
15:02:17 <graphitemaster> x-macro headers are not real headers
15:02:26 <_mjg> haha, this reminds me of "see a comment at foo_bar"
15:02:33 <_mjg> you go there and there is none
15:02:34 <graphitemaster> I only document the header
15:02:36 <geist> i have a tendency for closed, single image systems to comment the function instead of the declaration
15:02:50 <geist> which is what i had been doing in LK, but folks have been pointing out that i should move some of that to the .h
15:02:52 <graphitemaster> if there's some weird stuff happening in the code that I comment on but it's not a public facing documentation thing
15:02:55 <geist> and thats a good point
15:03:01 --- quit: atrapado_ (Quit: Leaving)
15:03:22 <geist> it really depends on if the commentary is to educate someone calling the api, or the implementer of the thing itself
15:03:33 <geist> but putting the same comment in both places is a great place for it to get stale
15:03:34 <_mjg> well, i think most comments which make any sense are at the beginning of the .c file
15:04:02 <graphitemaster> geist, this is one of the big reasons I prefer the implement-after-define in templated header code because more often than not, the definitions + documentation is already taking up so much of the header that having _code_ in there too is just confusing.
15:04:03 <_mjg> the rest should descrie something non-obvious
15:04:12 <geist> yeah depends. internal static functions sometimes need a one or two liner about what they're for
15:04:34 <_mjg> normally the name covers it, unless there are hacks and then see the above
15:04:35 <heat> the trick is to not comment anything
15:04:47 <geist> anyway, i'm going outside now. enough irc for one day
15:05:00 <heat> if there are no comments it can never get stale
15:05:00 <graphitemaster> heat, of course, all code should document itself by default
15:05:12 <_mjg> /* Tell the prison that we exist. */
15:05:12 <_mjg> prison_proc_hold(p2->p_ucred->cr_prison);
15:05:12 <heat> graphitemaster: Precisely
15:05:14 <_mjg> really?
15:05:18 <jjuran> Somewhere I have a Perl script that compares the include guard macro to the file subpath and complains if it doesn’t match.
15:05:49 <jjuran> Useful for catching failure to change the macro when copying a new module from an existing one.
15:05:56 <graphitemaster> _mjg, I hate obvious commenting the most like "if(user_exists(foo)) error("user already exists"); // error if user already exists
15:06:06 <_mjg> and that's the majority
15:07:33 <graphitemaster> _mjg, the dumbest comments I've seen in actual code
15:07:39 <graphitemaster> i++; // increment i
15:07:45 <_mjg> try this
15:07:50 <_mjg> # validate args
15:07:57 <_mjg> def validate_args(....)
15:08:04 <_mjg> no joke
15:08:19 <_mjg> there was one at the call site too
15:08:24 <graphitemaster> I can top it, memcpy(&a, &b, sizeof b); // copy b into a
15:08:27 <rain1> this is the sort of thing you get extra points in schools
15:08:28 <heat> musl has no comments, it's great!
15:08:31 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
15:08:55 <graphitemaster> I've also seen
15:08:59 <graphitemaster> return 0; // return 0
15:09:08 <rain1> haha
15:09:10 <_mjg> oh, right
15:09:23 <_mjg> best comments are those which repeat the code for no reason AND get the stale constant
15:09:28 <_mjg> or var for that matter
15:09:33 <heat> > //
15:09:47 <heat> return 0; /* return 0 */
15:09:50 <heat> FTFY
15:09:58 <graphitemaster> I've also seen
15:09:59 <_mjg> /* retval must be in range <8, 15> */
15:10:01 <_mjg> return 30;
15:10:14 <graphitemaster> return /* 1 used to be 1 but logic has moved */ 0;
15:10:18 --- quit: sortie (Quit: Leaving)
15:10:26 <geist> // blank line
15:10:26 <geist>
15:10:29 <dennis95> int one = 2; // Initialize this to three
15:10:32 <graphitemaster> geist, go outside
15:10:50 <_mjg> /* entry point */
15:10:53 <_mjg> int main
15:10:54 <graphitemaster> my favorite comment of all time tho is actually
15:11:08 <graphitemaster> // the following function implements the algorithm for X
15:11:15 <graphitemaster> (25k line function no comments at all)
15:11:20 --- quit: freakazoid0223_ (Ping timeout: 240 seconds)
15:11:29 <geist> yessir
15:12:04 <graphitemaster> a good example of this is the QR scanning code in zbar
15:12:22 <graphitemaster> that code is a minefield of good comments when you see them
15:12:32 <graphitemaster> but not enough commenting with all the magic algorithms and shit
15:12:49 <graphitemaster> https://github.com/graphitemaster/zbar-lite/tree/master/zbar/decoder/qrcode
15:12:50 <bslsk05> ​github.com: zbar-lite/zbar/decoder/qrcode at master · graphitemaster/zbar-lite · GitHub
15:12:54 <graphitemaster> go look at any one of those c files
15:13:19 <Kazinsal> The horror show that is zlib has /* the derivation of this formula is left as an exercise for the reader */
15:13:36 <_mjg> Kazinsal: and commit message "implement $formula"
15:13:40 <heat> I'd actually apreciate useless comments like those in musl
15:13:47 <heat> at least I'd be less lonely
15:13:58 <_mjg> swipe right on tinder
15:14:17 <heat> pretty sure women don't want to hack musl code
15:14:20 <heat> I might try tho
15:14:58 <graphitemaster> Kazinsal, I stopped using zlib when I wrote my own inflate/deflate code :P
15:15:03 <graphitemaster> I've no use for it now.
15:15:24 <heat> graphitemaster: Use libz
15:15:36 <graphitemaster> libz is larger than mine tho
15:15:43 <graphitemaster> (and still ugly)
15:15:56 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
15:16:01 <heat> At least sortie tries
15:16:17 <graphitemaster> 600 lines for inflate+deflate in C++
15:16:56 --- quit: renopt (Ping timeout: 272 seconds)
15:17:11 --- quit: epony (Max SendQ exceeded)
15:18:22 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
15:19:34 --- nick: ekr_ -> ekr
15:19:44 --- quit: ekr (Changing host)
15:19:44 --- join: ekr (~ekr@unaffiliated/ekr) joined #osdev
15:19:50 --- quit: Belxjander (Ping timeout: 240 seconds)
15:23:22 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:24:35 --- quit: azonenberg_work (Ping timeout: 246 seconds)
15:26:20 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
15:33:40 --- join: unixpickle (~alex@c-24-5-83-245.hsd1.ca.comcast.net) joined #osdev
15:33:59 --- quit: dennis95 (Quit: Leaving)
15:34:30 <rmf1723> I don't get how ELF program headers p_vaddr and p_align fields interact.
15:34:56 <heat> rmf1723: p_align is the alignment?
15:35:16 <Kazinsal> p_align is really useful for figuring out where to place a section if you're relocating it.
15:35:39 <heat> oh and checking if you can use MAP_SHARED or not
15:35:43 <rmf1723> The spec says that "The values of p_offset and p_vaddr must be congruent modulo the alignment."
15:36:01 <rain1> yeah that elf stuff is annoying
15:36:15 <heat> that stuff is useless
15:36:45 <froggey> p_vaddr % p_align == p_offset % p_align
15:36:47 --- join: hacku (~hacku@5070A9C0.static.ziggozakelijk.nl) joined #osdev
15:36:48 <rmf1723> Which they are in this ELF I'm looking at: offset 0x148, vaddr 0x600148, align 0x200000.
15:36:53 --- quit: xenos1984 (Quit: Leaving.)
15:36:59 <rmf1723> What I don't get is, where should I load this?
15:37:21 <froggey> at the vaddr
15:37:24 <rmf1723> At some address aligned to 0x200000, or at some address % 0x200000 = 148?
15:37:25 <rain1> well notice that vaddr - offset is a multiple of align
15:40:54 <hacku> Hello everybody, Could you help me? What the best way to define RAM size. I know about int 15, but it's available only from real mode. My bootloader switch cpu to protected mode at first steps, for easier accessing addresses. What's the best way for me now 1) use Virtual 8086 mode or jump back to real mode and then again to protected mode?
15:41:07 <heat> hacku, e820 map
15:41:08 <froggey> I forget exactly what the p_align field is useful for, iirc something related to mmap's alignment constraints and probably only relevant if you're loading a position-independent elf
15:41:17 <heat> That's what I was saying
15:41:23 <hacku> heat: please read question further )
15:41:26 <rmf1723> froggey: hah, this *is* a PIE
15:41:48 <heat> hacku: You had to get the memory map before jumping to protected mode
15:41:48 <froggey> ah
15:41:56 <heat> <heat> oh and checking if you can use MAP_SHARED or not
15:42:16 <heat> if(align == page_size) use_mmap_shared() else use_mmap_private
15:42:45 <hacku> heat: is it really easier than using Virtual 8086 mode ?
15:43:05 <heat> hacku: much easier
15:43:22 <heat> hacku: You kinda have to get memory maps and switch video modes before jumping to protected mode
15:43:41 <rmf1723> If I want to load it elsewhere, do I just need to ensure the position relative to the other segments is maintained?
15:43:52 <hacku> heat: Thank you very much
15:44:08 <heat> rmf1723: You kinda just get a new base address and increment everything by it
15:44:20 <froggey> from what I remember: you need to figure out the total in-memory size of the image and the maximum alignment of all load phdrs, allocate a single chunk of virtual address space with that size & alignment, then each load phdr is mapped at your_allocated_base + vaddr
15:45:16 <heat> This is my code: https://github.com/heatd/Onyx/blob/master/kernel/kernel/binfmt/elf64.c#L97
15:45:17 <bslsk05> ​github.com: Onyx/elf64.c at master · heatd/Onyx · GitHub
15:45:19 <heat> it kinda works
15:45:27 <rmf1723> Yeah, what weirds me out is that the vaddrs aren't aligned properly.
15:45:40 <heat> (pretty much works fine as far as I've tested, might find a bug though)
15:46:41 <froggey> they're aligned in such a way that the in-memory page offset matches up with the on-disk page offset, and the linker tries to pack each section together with no on-disk padding bytes
15:47:17 <heat> rmf1723: What do you mean with "aren't aligned properly"?
15:47:51 <froggey> p_vaddr % p_offset isn't guaranteed to be 0
15:47:54 <rmf1723> They are congruent with the file offset, as the spec says.
15:48:08 --- quit: Darmor (Quit: Leaving)
15:49:11 <rmf1723> I was having trouble understanding the point of p_align
15:51:19 <heat> rmf1723: It's kinda just a nice way of helping you relocate and mmap things
15:51:23 <graphitemaster> geist, wtf https://people.inf.ethz.ch/omutlu/pub/ambit-bulk-bitwise-dram_micro17.pdf
15:51:38 <graphitemaster> TL;DR = Thinking DRAM
15:52:35 --- quit: Shamar (Quit: leaving)
15:55:54 --- quit: hacku (Remote host closed the connection)
15:58:59 <doug16k> graphitemaster, I've seen EE lectures about that a while back. is it finally becoming a real thing?
16:00:13 --- quit: unixpickle (Read error: Connection reset by peer)
16:01:35 --- quit: atk (Quit: Well this is unexpected.)
16:01:47 --- join: atk (Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
16:06:11 --- quit: rw-r-r-0644[m] (Remote host closed the connection)
16:06:17 --- quit: equalunique[m] (Write error: Connection reset by peer)
16:06:18 --- quit: am2on (Read error: Connection reset by peer)
16:06:18 --- quit: Stary[m] (Read error: Connection reset by peer)
16:06:20 --- quit: Wallbraker (Remote host closed the connection)
16:06:21 --- quit: aesycos[m] (Read error: Connection reset by peer)
16:06:22 --- quit: ketanhwr (Remote host closed the connection)
16:06:22 --- quit: abvi[m] (Write error: Connection reset by peer)
16:08:50 --- quit: kleinweby (Ping timeout: 258 seconds)
16:09:50 --- quit: Belxjander (Ping timeout: 240 seconds)
16:09:57 --- quit: listenmore (Remote host closed the connection)
16:10:23 --- join: listenmore (~strike@2.27.123.231) joined #osdev
16:10:59 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:11:32 --- quit: awang (Ping timeout: 265 seconds)
16:11:34 --- join: kleinweby (~kleinweby@unaffiliated/kleinweby) joined #osdev
16:11:44 --- quit: svk (Read error: Connection reset by peer)
16:12:03 --- join: svk (~svk@p2003006A65481000B46E5035EE6F422E.dip0.t-ipconnect.de) joined #osdev
16:12:52 --- join: aesycos[m] (aesycosmat@gateway/shell/matrix.org/x-zhblqapeetezthtv) joined #osdev
16:14:21 --- quit: mpetch (Quit: No Ping reply in 180 seconds.)
16:15:36 --- quit: pg12 (Ping timeout: 276 seconds)
16:15:37 --- join: mpetch (~mpetch@vps2.gnubg.com) joined #osdev
16:18:25 <doug16k> nice, got MSI-X working - now nvme per-cpu queues have their completion IRQ routed to the appropriate CPU
16:19:05 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
16:20:09 --- join: pg12 (~pg12@p200300DBFBD342000EC47AFFFE6AAA70.dip0.t-ipconnect.de) joined #osdev
16:20:45 <heat> doug16k: What's so special about MSI-X?
16:21:40 <doug16k> you can allocate a lot more IRQs per device than MSI, the vectors don't have any alignment or contiguity restrictions, and you can route each IRQ to a specific CPU individually
16:22:20 <heat> Ah that's cool then
16:22:50 <heat> Although I didn't know the vectors had alignment restrictions?
16:23:34 <doug16k> multiple-msi has alignment restrictions. for example, if you have it configured to use a range of 16 IRQs, it must begin on a 16 boundary (vector 16-31)
16:23:49 <doug16k> or 32-47, etc
16:24:11 <doug16k> it's like that so the device can just stuff the index into the least significant bits, as a simplification
16:24:17 <doug16k> MSI-X relieves that restriction
16:24:48 <heat> oh crap I don't handle that
16:27:03 <heat> doug16k: Thanks :)
16:29:42 --- quit: quc (Ping timeout: 248 seconds)
16:29:57 <doug16k> 6.8.1.6 in pci spec. The Multiple Message Enable field (bits 6-4 of the Message Control register) defines the number of low order message data bits the function is permitted to modify to generate its system software allocated messages.
16:29:58 <doug16k> For example, a Multiple Message Enable encoding of “010” indicates the function has been allocated four messages and is permitted to modify message data bits 1 and 0 (a function modifies the lower message data bits to generate the allocated number of messages)
16:30:46 <doug16k> which is a way of saying, the logic only needs bitwise OR, not an adder
16:31:17 <doug16k> the digital logic I mean
16:33:36 --- quit: CheckDavid (Quit: Connection closed for inactivity)
16:34:31 <graphitemaster> doug16k, looks like it
16:34:44 <graphitemaster> doug16k, watch all the side channel attacks this will open up tho.
16:37:05 --- join: rw-r-r-0644[m] (rw-r-r-064@gateway/shell/matrix.org/x-cqhapibjsyfuuuwp) joined #osdev
16:37:05 --- join: abvi[m] (abvimatrix@gateway/shell/matrix.org/x-sheaxbzctjhsagih) joined #osdev
16:37:05 --- join: equalunique[m] (equaluniqu@gateway/shell/matrix.org/x-rjqyeiqtwoqrzefh) joined #osdev
16:37:05 --- join: ketanhwr (ketanhwrma@gateway/shell/matrix.org/x-dtzkeagpspjhtans) joined #osdev
16:37:05 --- join: Wallbraker (wallbraker@gateway/shell/matrix.org/x-giuiixmmpafhjpwp) joined #osdev
16:37:07 --- join: am2on (am2onataun@gateway/shell/matrix.org/x-fkdwaiyoecpzjlum) joined #osdev
16:37:10 --- join: Stary[m] (starymatri@gateway/shell/matrix.org/x-bbvnclkihuzecdjc) joined #osdev
16:37:42 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:40:05 <heat> which qemu ARM64 machine do you guys recommend?
16:40:30 <heat> virt looks to be a good one but it has no screen
16:41:19 <doug16k> heat, I've only touched the rpi one briefly. I think that one has a screen
16:41:22 <froggey> I'm using virt with a bunch of devices added, including screen, keyboard & mouse
16:41:28 <geist> virt is the one i use
16:41:44 <geist> virt is like a blank PC, you can add devices to it
16:41:56 <heat> froggey: Mind giving the command line options?
16:43:13 <froggey> qemu-system-aarch64 -machine virt -cpu cortex-a53 -device virtio-gpu-device -device virtio-keyboard-device -device virtio-mouse-device -drive if=none,file=/path/to/your/disk.image,id=blk -device virtio-blk-device,drive=blk -netdev user,id=vmnic,hostname=qemu -device virtio-net-device,netdev=vmnic
16:43:25 <heat> froggey: thanks :)
16:44:52 <geist> note that those devices are virtio, which sit on top of PCI, etc
16:45:11 <geist> so you need enough pci to find them and whatnot. it's worth it, but much more complex than dealing with a dumb ps2 or vga adaptor
16:45:20 <heat> that's exactly what I wanted
16:45:31 <froggey> these use the mmio transport, there's no pci bus
16:45:40 <froggey> or not any pci bus that I'm aware of
16:47:04 <heat> I think there's a way to add devices to a bus though?
16:48:12 --- join: tuxillo (~antonioh@89.128.97.235) joined #osdev
16:48:25 <froggey> idk
16:49:34 <heat> Oh, they're called "virtio-*-pci"
16:51:44 --- quit: svk (Ping timeout: 246 seconds)
16:51:46 --- join: retpolin_ (~clickjack@90.95.19.47) joined #osdev
16:52:21 <heat> froggey, geist, quick question: How am I supposed to detect memory and things like that?
16:53:54 <geist> on the arm64 virt? it comes in via a synthesized FDT
16:54:16 <geist> there's a field or two in there that gives the memory size. memory always comes in in one run on the arm64 virt build, so that's nice
16:54:25 <geist> it starts at 1GB+
16:54:33 --- quit: retpoline (Ping timeout: 265 seconds)
16:54:49 <heat> oh crap, device trees. I heard they were nasty?
16:55:12 <geist> if you're just looking for precisely one node in it and you know the node address, it's pretty easy to parse
16:55:25 <geist> most of the difficulty is because it's relatively irregularly structured
16:55:38 --- join: navidr (uid112413@gateway/web/irccloud.com/x-zusjscazucuciwss) joined #osdev
16:56:51 <heat> uhm, and all I need is a normal kernel image and the bootloader loads it?
16:57:57 <doug16k> I was a bit uneasy with emulating arm, since the emulator won't emulate any memory ordering problems, as far as I know
16:58:34 <doug16k> won't matter unless you want to do SMP though
16:58:46 <bcos> Matters for device drivers..
16:58:52 <doug16k> yeah
16:59:18 <bcos> ..but you can always do most testing with Qemu (and then switch to anything else for more testing)
17:03:16 --- quit: eivarv (Quit: Sleep)
17:03:17 <froggey> heat: I pretend to be a linux kernel and load with -kernel, not sure if there's a better way
17:05:12 <geist> doug16k: when doing nvme with plain non MSI based irqs on qemu, did you have to do anything funny?
17:05:29 <geist> we're having trouble with it, and it all goes into this particular irq pulsing logic inside qemu that seems suspicious
17:05:40 <geist> if it did work, what irq controller are you using? PIC or ioapic?
17:06:23 <heat> froggey: what do you mean with "pretend to be a linux kernel"? Is there anything special that I need to do?
17:06:26 <geist> re: using qemu to emulate arm. if you buy a $50 arm board that runs linux and can enable KVM (odroid-c2 is what i use)
17:06:41 <geist> then you can just run qemu + kvm, and then you do get the full memory order effect, and you dont have to bare metal bootstrap
17:06:48 <geist> i do it all the time, works nicely
17:07:24 <froggey> that's really good idea. I should get that set up on my board
17:07:29 <geist> key is not every little arm board lets linux get to EL2 and thus enable KVM. the broadcomm cpus in the RPIs for example mostly nerfs KVM
17:07:40 <geist> and plus most rpi distros are still 32bit
17:07:51 <geist> but an odroid-c2 i highly recommend. nice little simple board that runs linux pretty nicely
17:08:02 <geist> and only a little more expensive than a rpi
17:08:03 <froggey> heat: follow the linux boot protocol, it's a flat binary with a header on the front. pretty simple
17:08:31 <heat> froggey: oh ok, thanks
17:08:38 <froggey> and the arm linux boot protocol is totally different to the x86 boot protocol, make sure you look at the right one
17:09:09 <heat> yeah I know, the x86 boot protocol is completely wtf
17:09:47 <geist> neat thing is if you're willing to hard code your system to run on virt, or have multiple builds for different tagets, the simplest protocol is to just link it as an elf file
17:09:51 <geist> and then pass the elf file to -kernel
17:10:04 <geist> it'll blat it wherever you tell it. in this case i'd suggest 0x40800000
17:10:17 <geist> that's the default load address, and it'll put the FDT at 0x40000000
17:10:24 <geist> note that's the start of ram (1GB)
17:13:53 --- quit: garit (Ping timeout: 265 seconds)
17:16:53 --- quit: tacco\unfoog ()
17:18:47 --- join: John___ (~John__@79.97.140.214) joined #osdev
17:19:16 --- quit: Belxjander (Ping timeout: 255 seconds)
17:21:31 <doug16k> geist, no, I didn't have to do anything funny. I was using IOAPIC
17:21:42 <doug16k> today I added MSI-X so it's using MSI-X now
17:22:38 <doug16k> what happens that makes you need to do a workaround? IRQ storm? IRQs stop coming?
17:23:11 --- part: nilminus left #osdev
17:23:17 --- join: nilminus (~nilminus@45.76.139.171) joined #osdev
17:24:57 <doug16k> you handle IRQs in a separate thread right? the actual ISR just does something to wake up the irq thread?
17:25:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
17:25:30 <doug16k> if you have it decoupled like that, you should be writing the mask/unmask registers to temporarily mask the IRQ
17:26:13 --- quit: Arcaelyx (Read error: Connection reset by peer)
17:26:35 <geist> no irqs
17:26:49 <geist> yeah yeah, we got that. point is the initial irq doesn't fire
17:27:02 <geist> so i was thinking we weren't configuring the ioapic for edge or something
17:27:16 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:e0f3:1e3c:b677:51c4) joined #osdev
17:27:42 <geist> i'll probably end up taking a look at it next week or something. i'm for sure it's something we're not doing right, but the fact that it worked for you means it *can* work
17:27:49 <geist> and it's not just one of these bugs in qemu that no one sees
17:29:09 <doug16k> the way I do it is, in the ISR I do a callback, which typically wakes a condition variable of a waiting thread. I don't even need to touch the masks
17:29:49 <doug16k> if anything that would be the big difference
17:30:00 <doug16k> you do a DPC-like thing, with a worker thread
17:30:10 --- quit: dude1231- (Quit: Segmentation fault: 11)
17:30:26 <geist> yeah but we're not getting the IRQ in the first place, that's the problem
17:30:30 <doug16k> ah
17:30:34 <geist> so it's clearly some sort of setup with it
17:30:51 <geist> the keernel does all of the masking and delivery of irq and whatt to user space, that's been done
17:31:00 <geist> it's the setting up of the ir that seems problematic
17:31:36 <doug16k> do you have a link to the code handy? I'd be happy to look at the init and see if I notice something
17:32:22 <geist> will tomorrow
17:32:29 <doug16k> is this one good? https://fuchsia.googlesource.com/zircon/+/master
17:32:29 <bslsk05> ​fuchsia.googlesource.com: master - zircon - Git at Google
17:32:42 <geist> yeah that's the master
17:32:49 <doug16k> oh it's the patch set right? I'll find it in my history
17:33:00 <geist> what is, the nvme driver?
17:33:05 <doug16k> ya
17:33:16 <geist> the nvme driver doesn't touch the irqs at all, it's completely disconnected from irq delivery
17:33:27 <geist> it just asks for an irq object that is synthesized somewhere else
17:33:32 <geist> so the irq logic is embedded up in the kernel
17:33:40 <doug16k> how thoroughly does it reset? does it do a full reset?
17:33:48 <geist> reset the nvme? beats me
17:34:10 <doug16k> I do a reset. that could be a subtle difference
17:34:31 <doug16k> I'd guess you reset it but I'd check that first :)
17:34:31 <geist> could be. i seem to remember him discovering that not all devices support reset
17:34:59 <geist> like i said, he's sitting right there in #fuchsia
17:38:13 --- join: dude12312414 (None@gateway/shell/elitebnc/x-mefmmpkabpjkvwqz) joined #osdev
17:49:35 --- join: azonenberg_work (~azonenber@172.58.41.255) joined #osdev
17:50:45 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
17:50:45 --- quit: plonk (Changing host)
17:50:45 --- join: plonk (~plonk@unaffiliated/plonk) joined #osdev
17:50:58 --- quit: daniele_athome (Ping timeout: 256 seconds)
17:52:30 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
17:57:42 * bcos wonders if there's a #zircon channel :-)
17:58:30 <heat> bcos, nope
17:58:31 <latentprion> geist: Are you going to be implementing fixes (separate kernel vaddrspace, etc) for LK?
17:58:39 <heat> Quick, someone register it!
17:59:07 <latentprion> Or had you done it already? Technically, Google was aware of the bugs since last year, and they already did the retpoline and other fixes to their codebase
18:02:43 --- quit: zwliew (Quit: Connection closed for inactivity)
18:13:19 --- quit: mmu_man (Ping timeout: 264 seconds)
18:13:25 <geist> not to LK, it already is single addres space
18:13:36 <geist> but zircon, yeah. i was not aware of it until the same time as everyone else
18:15:20 <latentprion> geist: What was your reason for making LK have its own address space before this?
18:15:58 <geist> because it primarily runs on cpus with no mmu
18:16:10 <geist> it's supervisor only, embedded. single address space
18:16:27 <latentprion> Oh, ok, even the x86 port?
18:16:52 <latentprion> Single address space, I mean
18:16:53 <geist> yes, the x86 port is pretty minimal. basically just the minimum to work. mostly submitted by other folks
18:17:05 <latentprion> Right, np np
18:17:23 <heat> let qualcomm do their own mitigations
18:17:58 <geist> well, basically LK is a kernel that you can run code in, so for machines with no mmu you just run it
18:19:15 <geist> which is where LK primarily runs. but, then you can add a user space to it, which is what projects like Trusty or Zircon do
18:19:32 <heat> geist: What's trusty?
18:19:44 <geist> https://source.android.com/security/trusty/
18:19:45 <bslsk05> ​source.android.com: Trusty TEE  |  Android Open Source Project
18:20:12 <geist> that's beena round for quite a few years. lots of android devices use it
18:20:23 <geist> basically it's the little secure os that runs over in a secure enclave underneath linux
18:20:30 <heat> oh that's cool
18:20:32 <geist> and does DRM stuff
18:20:43 <heat> so LK is probably running on my phone right now?
18:20:54 <geist> there's a chance. if it's qualcomm based they have their own
18:20:59 <geist> based on L4 I believe
18:21:22 <geist> and for newer bootloaders, qualcomm appears to be moving away from their LK fork and using some sort of UEFI thing
18:21:36 <geist> i think just built on topo of the same open source UEFI that everyone else does. tianocore? something like that
18:21:52 <heat> ye tianocore
18:21:59 <geist> i think it's primarily because their fork is based on an ancient copy of LK from 2008, pre arm64
18:22:13 <geist> and instead of backporting arm64 support from newer LK, they are moving off to something else.
18:22:16 <geist> so it goes.
18:22:51 <heat> geist: Why UEFI on a smartphone though?
18:22:56 <heat> seems odd
18:23:53 <geist> arm is pushing pretty hard for UEFI on arm64 to try to standardize the boot envirobment for future arm stuff
18:24:00 <geist> which i completely support the idea of doing
18:24:17 <geist> vs not having any srt of standard environment at all, it's a total win
18:24:59 <heat> well isn't the FDT a standard-ish environment?
18:25:17 <geist> sure, but uefi and FDT can absolutely coexist
18:25:20 <heat> and afaik ACPI supports ARM as well
18:25:23 <geist> right
18:25:41 <Mutabah> geist: Pity it's UEFI though
18:25:45 <geist> there's nothing at all that says the UEFI implementation doesn't pass off a FDT to the kernel, if it wants it
18:25:50 * Mutabah shudders at the UCS-2 everywhere
18:26:01 <geist> i'm mmore annoyned with FAT
18:26:08 <heat> It doesn't need to be FAT though
18:26:21 <geist> *technically* it does, according to the UEFI stuff
18:26:22 <heat> it just has to *support* FAT
18:26:27 <geist> but you can deviate
18:26:33 <geist> and they do, mac uses HFS or whatnot
18:26:36 <heat> you can add your own filesystems
18:26:37 <heat> yeah
18:26:45 <Mutabah> :/ FAT isn't as bad imo, it's the defacto standard interchange filesystem, so everything supports it
18:27:01 <geist> yeah i know, but you can't complain about UCS-2 and not complain about FAT
18:27:14 <Mutabah> but UCS-2 is completely against the grain of every modern programming language
18:27:18 <heat> UCS-2 isn't that bad in UEFI's case
18:27:31 <geist> FAT is against the grain of every modern fs :)
18:27:33 <heat> you kinda just need a L"" on what? every Print()?
18:27:58 <heat> I don't see where else you'll have problems with UCS-2
18:27:58 <geist> yah i ont treat ucs-2 as functionally any different than operating on a machine where char == 16 bits
18:28:29 <geist> as long as you can implement all of your printfs and strlens and whatnot, it doesn't matter
18:28:33 <heat> and the API is quite good
18:28:47 <heat> geist: at least gnuefi supplies those
18:29:00 <geist> yah
18:29:11 <geist> that is it's own monstrosity, but only just an implementation detail
18:29:22 <geist> it does do what it sets out to do
18:29:33 <Mutabah> I guess it's mostly that I've been using rust, where `str` is utf8
18:29:33 <heat> I can definitely say programming for UEFI is fun
18:29:42 <Mutabah> and ucs2 literals are a pain
18:29:44 --- quit: John___ (Read error: Connection reset by peer)
18:29:50 <geist> yah that makes sense
18:30:45 --- join: aosfields_ (~aosfields@172.58.140.130) joined #osdev
18:32:39 --- join: Youmu (uid129469@gateway/web/irccloud.com/x-gwnuetpsjblmbtjn) joined #osdev
18:32:52 --- nick: Youmu -> Guest49834
18:33:12 --- quit: Guest49834 (Changing host)
18:33:12 --- join: Guest49834 (uid129469@unaffiliated/condy) joined #osdev
18:33:12 --- quit: Guest49834 (Changing host)
18:33:12 --- join: Guest49834 (uid129469@gateway/web/irccloud.com/x-gwnuetpsjblmbtjn) joined #osdev
18:33:58 --- quit: Belxjander (Ping timeout: 248 seconds)
18:34:13 --- join: garit (~garit@94.197.121.75.threembb.co.uk) joined #osdev
18:34:13 --- quit: garit (Changing host)
18:34:13 --- join: garit (~garit@unaffiliated/garit) joined #osdev
18:38:18 <doug16k> I got all carried away in my FAT LFN implementation. even my bootloader handles UTF-16 surrogate pairs in filenames D:
18:38:38 <Mutabah> fanceh
18:39:08 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:39:23 <Kazinsal> https://www.ebay.com/itm/RARE-APPLE-LISA-1-TWIGGY-COMPUTER-COMPLETE-AND-WORKING-with-Video/182999855120 The current bid on this is *FIFTY FIVE THOUSAND DOLLARS*. :O
18:39:26 <bslsk05> ​www.ebay.com: RARE APPLE LISA 1 TWIGGY COMPUTER - COMPLETE AND WORKING with Video | eBay
18:41:12 <geist> yah a buddy of mine showed me his collection. he had 2 of them, completely functional
18:43:37 <doug16k> Kazinsal, shipping, $990.00
18:43:55 <geist> yeah h'd hope. something that fragile i'd hope someone delivers it on a cloud of feathers
18:44:15 <Kazinsal> I think if I were buying a computer for more money than most people make in a year I'd drive out and pick it up myself
18:44:18 <geist> you do not want to shock old hardware like that. pieces fall off
18:44:23 <geist> Kazinsal: yeah totally
18:44:43 <Kazinsal> Item location:
18:44:43 <Kazinsal> Karlsdorf-Neuthard, Germany
18:44:48 <Kazinsal> Okay, maybe I wouldn't drive out there
18:44:56 <geist> really the key is the type of folks that buy and collect hardware like that, $55k is no big thing. it being $55k vs $56k is noise
18:45:03 <Kazinsal> Yeah
18:45:14 <geist> the buddy of mine that has two of these, lets say the price is not a concern
18:45:38 <geist> maybe buy one less supercar this year and you can buy a few more Apple 1s or Lisas
18:46:17 <Kazinsal> For 55k USD I could buy a first generation NSX. Or put a 15% down payment on a townhouse.
18:46:55 <geist> funny, hes also big into collecting NSXes
18:47:07 <geist> tried to sell me one. got a chance to drive it. it drives niiiiiice
18:47:18 --- nick: Guest49834 -> Youmu
18:47:18 <geist> except the lack of power steering. but the shifter was damn nice
18:47:42 <Kazinsal> Yeah, they're something else
18:47:55 <Kazinsal> Apart from the manual steering they totally don't feel circa 1991
18:47:58 <geist> basically a cheap supercar you can actually fix
18:48:01 <geist> and dont fall apart
18:48:17 <Kazinsal> And isn't so terribly overpowered it wants to kill you
18:48:22 <geist> right
18:48:43 --- quit: Belxjander (Ping timeout: 264 seconds)
18:48:46 <geist> some folks will argue that that's the appeal of a vintage lamborghini or something
18:48:50 <geist> it tries to kill you constantly
18:49:37 <geist> a couple years ago i saw a straight up classic Countach on the freeway. that thing is extremely striking
18:50:03 <geist> that's the canonical terrible but completely awesome supercar that tries to kill you and falls apart constantly
18:50:40 <Kazinsal> Yeah. Beautiful machine but I'm content at just seeing them once in a blue moon
18:50:40 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:51:59 <heat> geist: Is there any standard-ish mapping for aarch64 kernels?
18:52:25 <heat> like 0xffffffff8000000 for x86_64 and 0xC0000000 for i386
18:53:01 <geist> not really. ARM64 is largely position independent
18:53:22 <geist> and for all practical purposes doesn't have any memory models
18:53:45 <geist> so i for lack of anyother reason picked -4GB to map it, since i put at the base of the kernel (0xffff.0000.0000.0000) the big kernel mapping
18:53:45 <heat> I saw it has a -mcmodel option though?
18:54:05 <geist> it doesn't do what you think. i think it only changes how the code fetches TLS, which system regs it uses
18:54:33 <heat> oh yeah, I have the full 64 bits of address space now
18:54:50 <geist> yeah each half of the address space has a full 48 bits
18:54:59 <geist> and, arm64 supports 1GB pages always, so you can just straight up start using them
18:55:39 <geist> the exception model is a real treat, the way it takes exceptions and IRQs
18:55:44 <geist> you'll have fun with that. so elegant
18:55:56 <geist> oh gotta go. bbiab
18:56:50 --- quit: zng (Ping timeout: 265 seconds)
18:58:06 --- quit: azonenberg_work (Ping timeout: 276 seconds)
19:20:02 --- quit: Belxjander (Ping timeout: 265 seconds)
19:22:43 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:27:01 <heat> what do I do if qemu doesn't like my aarch64 image?
19:27:15 <latentprion> Ask it why
19:27:44 <heat> I was trying to boot an elf image like geist said
19:28:33 <geist> it does the usual thing where it follows the physical load
19:28:45 <geist> so you have to set the AT address and whatnot to somewhere around 0x4000.0000
19:29:09 <geist> or just get it a completely flat binary and it will just plunk it at 0x4080.0000 iirc
19:29:26 <heat> I tried but it just gets stuck at 0x200 with invalid instructions
19:29:51 <geist> well, sounds fun to debug then
19:29:53 <Mutabah> heat: What machine?
19:30:00 <Mutabah> (as in, what -M option)
19:30:06 <geist> 0x200 sounds to me like it took an exception and your vector table is still set to 0
19:30:08 <heat> Mutabah: virt, cpu cortex-a53
19:30:19 <geist> you have to set the vector table by writing to the VBAR_EL1 register
19:30:31 <geist> 0x200 is one of the offsets, iirc
19:30:39 <Mutabah> Ah, that's why it's familiar
19:30:58 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/exceptions.S#291
19:30:59 <bslsk05> ​fuchsia.googlesource.com: kernel/arch/arm64/exceptions.S - zircon - Git at Google
19:31:10 <heat> geist: my entry point is just int kernel_start(){void *fdt = 0x40000000; while(1)}
19:31:22 <geist> well, debugging time!
19:31:38 <Mutabah> `-d int` :D
19:31:53 <heat> Mutabah: -d int spams me with ints ;)
19:32:10 <geist> yes, thats becuase you should actually look at them
19:32:22 <geist> it's screaming at you, trying to tell you something
19:32:50 <geist> i think you're sitting there effectively triple faulting, except arm has no such thing. it's in an exception loop where it faults in a loop
19:33:03 <heat> nope those are just exceptions at 0x200(I think)
19:33:11 <geist> yes..... and....
19:33:16 <geist> that is a gigantic hint
19:33:35 <heat> it is?
19:33:41 <Mutabah> yep
19:33:51 <geist> dude i've totally just explained it to you
19:34:00 <heat> well, yes, I got that part
19:34:16 <geist> soooo maybe you should figure out what the very first exception it was trying to deliver was?
19:34:22 <Mutabah> More explitic tip - 99% of those are useless, what was the first?
19:34:25 <geist> and then all the subsequent ones are it just faulting in a loop
19:34:27 <heat> yeah that's what I was trying to do
19:34:35 <heat> Mutabah: Gets lost in the scrollback
19:34:47 <Mutabah> You can pass `-D filename` to send those logs to a file
19:34:51 <geist> if only there was some way to redirect output of a program to a file or something....
19:34:57 <heat> Mutabah: ooh nice
19:35:05 <Mutabah> Or, as geist said
19:35:31 <geist> anyway if you *literally* set that as your entry point i can think of at least a few thins that'll cause it to immediately explode
19:35:47 <geist> do not pass go sort of stuff
19:36:06 <heat> I got a data abort, apparently
19:36:16 <heat> Oh yeah
19:36:20 <heat> makes total sense
19:36:38 <geist> cool, and the ESR contains the reason and some bits about it, and the FAR contains the address it faulted on, which i dunno if that prints
19:36:48 <heat> sp - 8 = 0xfffffffffffffff8, doesn't exist, bam crash
19:37:18 <geist> bingo.
19:37:37 <geist> so you'll need a little asm trampoline to at least set the SP. and warning: SP must be 16 byte aligned at all times on ARM64
19:37:43 <Mutabah> I'd say "called it", but I wasn't thinking hard enough to see that particular problem
19:37:52 <geist> Mutabah: oh i saw it a mile away.
19:38:15 <Mutabah> I saw the C entrypoint and knew that something wasn't going to work with it :)
19:38:25 * Mutabah wanders back to paying work
19:38:36 <heat> x86 would usually just have a random sp set by the bootloader
19:38:41 <geist> then the second thing you'll want to do ASAP is set up at least some dumb exception vectors that loop or something, and set the VBAR_EL1 system register to that
19:39:10 <geist> yah in the case of booting from qemu, there is no bootloader at all, qemu just sets the PC to your entry point and explicitly sets all the other regs to 0
19:40:09 --- quit: Arcaelyx (Quit: Textual IRC Client: www.textualapp.com)
19:42:41 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:1c28:81e1:57dd:4197) joined #osdev
19:52:47 --- quit: navidr (Quit: Connection closed for inactivity)
19:52:57 <heat> wtf gas arm syntax is so confusing
19:53:30 <Mutabah> Iirc it's actually ARM's native syntax
19:53:52 <latentprion> Yup
19:58:57 <geist> oh yeah? i find it quite simple
19:59:05 <geist> it's regular and unambiguous
20:01:32 --- nick: Guest46668 -> mischief
20:02:33 <geist> heat: which part is giving you grief?
20:03:30 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
20:03:32 <heat> geist: The whole register naming thingy
20:04:00 <heat> (I know that that's not the syntax, but still)
20:04:27 <heat> then you have to use a '=' for expressions(?)
20:04:38 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
20:04:38 --- nick: Halofreak1990_ -> Halofreak1990
20:05:29 <heat> I'm just generally confused at the whole arm assembly thingy
20:05:50 --- join: srjek (~srjek@2601:249:601:9e9d:95f8:d0b5:8a91:680b) joined #osdev
20:06:41 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-bzezydlxvpgjcimr) joined #osdev
20:07:11 <geist> well, okay
20:07:29 <geist> yeah the naming of the registers as x and w is a bit weird. i think that was specifically to be different from arm32s use of 'r'
20:07:49 <geist> but that's just the 64bit reg and the 32bit subreg, which usually results in an actual bit on the instruction
20:08:08 <geist> and in general the cpu will sign or zero extend the top part of the reg if it's a w variant
20:08:11 --- part: Kazinsal left #osdev
20:08:17 --- join: Kazinsal (~Kazinsal@unaffiliated/blacklightos) joined #osdev
20:08:39 <heat> why does "ldr sp, =stack" not work?
20:08:39 <geist> the = thing is a bit strange yes, that's if you want to just get an arbirtrary value into the reg and tell the assembler to figure it out
20:09:14 <heat> I mean, sp is register, I think?
20:09:30 <geist> not really. you have to move to SP
20:09:41 <geist> so load another reg and then move to SP. you can't arbitrarily load into SP
20:09:47 <heat> why?
20:09:58 <geist> it's a decidion arm made on arm64, but SP is not in the general register bank, nor is PC
20:10:06 <geist> it's a special register, you can't do a lot of ops on it
20:10:23 <geist> but you can use it as a base reg for load stores and whatnot, but you can't do arbitrary math on it
20:11:39 <geist> you should at least familiarize yourself with the registers and whatnot before going on too much farther
20:12:01 <geist> like x0-x30 are the main ones, x30 is sometimes also referred to as lr, x31 == xzr, and is always zero
20:12:36 <geist> when there's a frame poiinter, it uses r29
20:12:39 <geist> x29 even
20:12:50 --- join: adu (~ajr@pool-173-66-242-131.washdc.fios.verizon.net) joined #osdev
20:13:53 <heat> ah okay, I think I'm starting to get it
20:14:00 <heat> thanks geist
20:14:37 <geist> SP and PC can be used as a base register sometimes, but you generally can only move into and out of SP (and use post/pre indexed load/stores on it) and PC can generally only be used as a base (for pc relative stuff)
20:14:59 <geist> the other one you'll see pretty quickly is there is no push/pop instruction, nor are there load/store multiple like on arm32
20:15:17 <geist> but... there is ldp/stp, which load/stores an arbitrary pair of registers
20:15:28 <geist> and you can make a mini push/pop out of it with some macro trickery
20:15:59 <adu> geist!
20:16:04 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/include/arch/asm_macros.h#27
20:16:05 <bslsk05> ​fuchsia.googlesource.com: kernel/arch/arm64/include/arch/asm_macros.h - zircon - Git at Google
20:16:32 <adu> fuchsia is such a cool os
20:16:37 <geist> ignoring all that .cfi stuff that's how you can make a pseudo push/pop thing
20:16:48 <heat> geist: Oh yeah, and there's no div as well right?
20:16:57 <geist> yeah there's totally a div
20:17:06 <heat> I thought arm had no div?
20:17:12 <geist> you thought wrong
20:17:27 <heat> ah, that's cool then
20:17:28 <geist> old ARM cores didn't, but they added it by the later half of armv7, and it's non optional on armv8 and arm64
20:17:34 <geist> adu: neat
20:18:04 <heat> well, i'm going to bed since I have to "wake up" in 3 hours
20:18:27 --- quit: heat (Remote host closed the connection)
20:18:28 <geist> oh hah
20:18:37 <adu> neat?
20:18:41 <geist> someone new is starting down the arm64 path
20:18:47 <geist> adu: neat that you think that
20:19:03 <adu> I'm studying x86 again
20:19:14 <adu> for a job interview
20:19:44 <geist> well, grats i guess
20:29:32 --- quit: pictron (Ping timeout: 264 seconds)
20:30:16 --- join: azonenberg_work (~azonenber@2001:470:ea80:2:2ab2:bdff:fe8a:439b) joined #osdev
20:54:47 --- quit: osa1 (Remote host closed the connection)
20:55:02 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
20:55:23 --- join: osa1_ (~omer@212.252.142.138) joined #osdev
20:55:30 --- quit: osa1_ (Remote host closed the connection)
20:56:43 --- quit: adu (Quit: adu)
20:57:20 --- quit: Belxjander (Ping timeout: 240 seconds)
20:59:30 --- join: oaken-source (~oaken-sou@p3E9D2B74.dip0.t-ipconnect.de) joined #osdev
21:01:53 --- join: Humble (~hchiramm@106.206.90.85) joined #osdev
21:02:45 --- quit: osa1 (Remote host closed the connection)
21:03:02 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
21:03:14 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:11:47 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:12:45 --- join: genBTC (~genBTC@unaffiliated/genbtc) joined #osdev
21:16:22 --- quit: ohnx (Ping timeout: 250 seconds)
21:18:56 --- quit: fusta (Ping timeout: 265 seconds)
21:23:51 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
21:24:06 --- quit: daniele_athome (Ping timeout: 248 seconds)
21:24:52 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
21:30:00 --- quit: genBTC (Quit: My computer is probably rebooting.)
21:30:48 --- quit: Belxjander (Ping timeout: 268 seconds)
21:31:22 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:38:51 <gamozo> Dammit! My build ran out of disk
21:38:57 <gamozo> now i gotta start allllllll over again
21:40:43 --- quit: freakazoid0223 (Quit: Copywight 2016 Elmer Fudd. All wights wesewved.)
21:41:10 --- quit: Belxjander (Ping timeout: 265 seconds)
21:43:12 --- quit: srjek (Ping timeout: 276 seconds)
21:47:49 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:52:16 --- join: fusta (~fusta@139.179.50.177) joined #osdev
21:54:03 --- quit: epony (Quit: QUIT)
21:55:03 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:14:31 --- quit: lowl3v3l (Ping timeout: 265 seconds)
22:16:22 --- quit: jjuran (Ping timeout: 248 seconds)
22:23:42 --- quit: aosfields_ (Ping timeout: 265 seconds)
22:32:22 --- quit: SlashLife (Changing host)
22:32:22 --- join: SlashLife (~slashlife@botters/slashlife/bot/scriptkitty) joined #osdev
22:32:57 --- quit: SlashLife (Changing host)
22:32:57 --- join: SlashLife (~slashlife@botters/slashlife) joined #osdev
22:38:50 --- quit: Belxjander (Ping timeout: 240 seconds)
22:43:18 --- join: user10032 (~Thirteen@90.209.104.11) joined #osdev
22:44:20 --- join: jjuran (~jjuran@172.58.185.207) joined #osdev
22:46:04 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
22:46:25 --- quit: dbittman (Ping timeout: 255 seconds)
22:48:07 <geist> gamozo: needs moar disk mang
22:50:27 <Kazinsal> gotta have that terabyte NVMe drive as build scratch
23:05:58 --- quit: Belxjander (Ping timeout: 248 seconds)
23:07:58 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:08:44 <gamozo> i have to use platter, I put my 10TB in there
23:09:01 <gamozo> i only have 2TB of SSDs laying around that I could raid 0, and 2TB i dont think will be enough
23:09:04 <gamozo> it might be barely cutting it
23:10:49 --- join: moondeck[m] (moondeckma@gateway/shell/matrix.org/x-usrxlfdktsjgcliz) joined #osdev
23:13:31 --- join: rap_hael (~raphael@2a00:dcc0:dead:a066:216:3cff:feae:868a) joined #osdev
23:13:39 --- quit: equalunique[m] (*.net *.split)
23:13:39 --- quit: raph_ael (*.net *.split)
23:13:39 --- quit: swetland (*.net *.split)
23:13:39 --- quit: lecx (*.net *.split)
23:14:11 --- join: swetland (sid155178@gateway/web/irccloud.com/x-gcmqybwlkpvlbtwt) joined #osdev
23:15:08 --- join: equalunique[m] (equaluniqu@gateway/shell/matrix.org/x-ydcswcxxxzrqpvru) joined #osdev
23:16:43 --- quit: heinrich5991 (Ping timeout: 260 seconds)
23:16:50 --- quit: daniele_athome (Ping timeout: 240 seconds)
23:17:20 --- quit: Belxjander (Ping timeout: 240 seconds)
23:18:30 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
23:22:57 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:23:38 --- quit: xenos1984 (Ping timeout: 265 seconds)
23:26:30 --- join: heinrich5991 (~hein5991@unaffiliated/heinrich5991) joined #osdev
23:28:57 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
23:33:11 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
23:34:53 --- quit: epony (Max SendQ exceeded)
23:35:15 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
23:35:44 <geist> that being said for general building of source codes i've found that i fyou have enough ram to cache everything you usually can't generate .o files fast enough for a spinny disk to be a bottleneck
23:36:18 <geist> it's really only in that initial load with the seeking and whatnot to read in source, and then enough -j basically wipes that out
23:40:18 --- quit: Belxjander (Ping timeout: 268 seconds)
23:42:31 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:42:48 --- quit: wcstok (Read error: Connection reset by peer)
23:44:12 --- quit: eivarv (Quit: Sleep)
23:46:27 --- join: JackyLi (~Thunderbi@222.195.150.54) joined #osdev
23:50:14 --- quit: daniele_athome (Ping timeout: 256 seconds)
23:51:32 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
23:52:18 --- quit: Belxjander (Ping timeout: 260 seconds)
23:53:01 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:57:26 --- join: k4m1 (~k4m1@82-181-0-34.bb.dnainternet.fi) joined #osdev
23:59:59 --- log: ended osdev/18.01.07