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=11&d=12
12:01:12 <eryjus> Building deep on top of flaws like that does not seem like a good idea...
12:18:19 <geist> hah also fun comparison: on this random piledriver AMD machine the difference between hw and sw task switching is 40x
12:18:26 <geist> ie, 40mil/sec vs 1mil/sec
12:19:25 <geist> also fun note: if you plug in a usb floppy drive it boots it just fine in compatibility mode
12:23:33 <aalm> we would have round wheels w/o all that backwards compat crp
12:24:14 <aalm> *could
12:24:51 <geist> anyway, to put away the age old question of if hardware or software task switching is faster on x86... it's hella slow
12:25:04 <geist> by at least one order of magnitude
12:25:14 <aalm> which
12:25:19 <geist> hardware
12:25:34 <geist> it's a known fast that tss context switching is slow, but i haven't seen any hard numbers, so i just tested it manually
12:25:37 <diodesign> i always thought that to be ironic
12:25:46 <olsner> interesting that it wasn't even faster originally... unless maybe it was on a 286?
12:26:02 <geist> but i was a little surprised it was already slow on this 386. exactly olsner
12:26:41 <geist> my guess is it's still a little quicker if you're building less of a centralized monolithic kernel, and doing more of fast switches directly between user threds
12:26:58 <geist> since you can skip a user -> kernel -> switch -> kernel -> user transition
12:27:39 <geist> so if you have some sort of fast DOS TSR or something where you just want to flip it into a different context and then jam it back, it at least probably involves less instructions
12:28:01 <aalm> i c what you did there
12:28:22 <geist> or making fare calls over to some other context
12:28:26 <geist> far even
12:29:53 <olsner> grand ideas about what clever things an OS could do with very little code based on good hardware task switching, busted by everyone just doing the simplest thing instead
12:30:32 <geist> also: marketing. features you have on your processor (286) to try to get folks to buy it
12:30:55 <geist> dedicated io instructions! hardware task switching! whee! these are neat, lets buy one of these for <project>
12:31:53 <geist> there was some interview i saw with the 386 designers and they were complaining that the microcode to do a TSS switch was crazy complex, and wayy worse on 386. i guess it had to handle all these 16/32/paging transitions
12:33:21 <aalm> when was it removed?
12:33:29 <geist> it wasn't. modern machines still have it
12:33:35 <geist> i just tested it on a 2014 era PC
12:37:06 <mrvn> amd64 dropped task gates though making HW switching truely pointless.
12:38:12 <mrvn> geist: they should have limited to switching between the same modes and removed other corner cases nobody uses anyway.
12:40:13 <mrvn> If ARM only had one extra banked register it would be perfect. *sigh*
12:42:36 <mrvn> geist: did you test TSS on a 286?
12:49:50 <klange> got my package manager actually supporting multiple remotes; now I can set it up to pull from the local CD repo as well as from the network repo...
01:25:13 <Maka_Albarn> For some reason I can't get the memory map from GRUB. I can get upper and lower memory, but I get a whole bunch of other stuff instead of the memory map. Can anyone look at my tags and see if I screwed something up?
01:25:15 <Maka_Albarn> https://gist.github.com/MakaAlbarn001/92409c15457293cb3a7a458a412256ea
01:25:25 <geist> yeah you probably got an offset wrong in there
01:25:35 <geist> iirc there's a flag that says its some longer format or something, i think
01:25:46 <geist> or maybe not, i forget
01:31:35 <eryjus> Maka_Albarn: each type sub-structure needs to be aligned.
01:32:41 <Maka_Albarn> eryjus: 8-byte?
01:34:09 <Maka_Albarn> the sub structures are aligned.
01:34:56 <eryjus> i'm comparing mine to yours and I have much more I am asking of Grub than you are -- so I'm back in the docs
01:35:52 <geist> recommendation: comment what those constants are
01:35:57 <geist> ie. short 1, long 4, etc
01:37:11 <eryjus> I also believe you have the info as optional (second .short field)
01:38:12 <Maka_Albarn> no I don't. flags needs to be 1 if the info is optional.
01:38:20 <Maka_Albarn> multiboot documentation.
01:38:30 <Maka_Albarn> pg. 6
01:38:33 <geist> suggestion: link the docs you're reading
01:38:46 <geist> here and in the source
01:39:15 <eryjus> mid-read that several times... it's even coded as '1' in my code.... oope
01:39:16 <eryjus> oops
01:39:33 <Maka_Albarn> https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html#Information-request-header-tag
01:40:33 <geist> fwiw this is the one i have: https://github.com/littlekernel/lk/blob/master/arch/x86/32/start.S#L53
01:40:52 <geist> though its so old i dont even remember writing it. and the flags aren't documented. bad me!
01:41:26 <geist> also i guess that's multiboot 1
01:41:29 <eryjus> and here is mine: https://github.com/eryjus/century-os/blob/master/modules/loader/src/i686/entry.s#L99
01:42:14 <eryjus> i have both MB headers in mine and both work. I think I remember i had problems with the MBI structure coming back, not the actual header
01:46:24 <Maka_Albarn> eryjus: I didn't see any multiboot information request tag.
01:46:59 <diodesign> klange: pretty cool!
01:54:19 <eryjus> Maka_Albarn: That's a good call-out and i second guessed myself. I did boot from a saved image and I am getting the memory map data with MB2 -- even without that request block
01:55:19 <Maka_Albarn> ???
01:55:33 * Maka_Albarn is very confused.
01:55:48 <geist> is it possible according to the spec for it to just tell you things you didn't ask for?
01:55:59 <geist> and thus it's your responsibility to skip info you dont understand?
01:56:15 <geist> may be that essentially all implementations dont bother to parse the info requests, and they just giv eyou all the infos
07:18:55 <SopaXorzTaker> If reading a CD (DL = 0xe0) with int 13h (AH = 0x42), what's the actual sector size
07:19:02 <SopaXorzTaker> Is it 512 bytes or 2048 bytes?
07:23:44 <bcos_> SopaXorzTaker: 2 KiB
07:24:09 <SopaXorzTaker> bcos_, so the new BIOS routines perform reads properly and are aware of the varying sector sizes?
07:24:11 <SopaXorzTaker> cool!
07:24:13 <bcos_> (unless CD is emulating floppy or hard disk)
07:24:20 <bcos_> Yes
07:24:20 <SopaXorzTaker> bcos_, no, no emulation
07:24:48 <SopaXorzTaker> so I give those routines the LBAs I want and get the proper sectors in return?
07:24:53 <SopaXorzTaker> Amazing.
07:27:28 <klange> quick little minor release update for ToaruOS: https://github.com/klange/toaruos/releases/tag/v1.8.1
08:15:45 <bauen1> tcp is happening :D http://i.imgur.com/4pVvh0s.png (well, the starting sequence number is generated at compile time by messing with __TIME__, but who cares ?)
08:16:46 <klange> yay
08:16:50 <geist> woot
08:16:51 <diodesign> nice
08:17:17 <geist> getting a net stack going is a lot of fun and really makes it click, somehow
08:17:31 <geist> makes your thing you made feel real
08:17:37 <bauen1> yup
08:17:49 <klange> i get this weird satisfaction out of watching a progress bar showing a download in progress
08:17:53 <bauen1> i'm also going for a full network stack with routing
08:18:15 <bauen1> it's only fun if you can use your os as a router
08:18:40 <geist> word
08:18:51 <geist> i thought about that a few years back, figured it'd be fun
08:20:35 <klange> [and then I remember I've downloaded the same GCC package from my server a hundred times and I'm using up all my data]
08:20:50 <geist> you said package
08:21:30 <klange> ... yes?
08:22:03 <geist> it's not as fun as a full defrag of a spinny disk, but trimming your ssd has a kind of pleasure to it
08:28:37 <lkurusa> ya the network stack is a lot of satisfaction
08:28:49 <lkurusa> i had so much having mine run baremetal on a laptop while i was in china
08:29:18 <lkurusa> the great firewall, and the latency can test it quite well
08:29:22 <lkurusa> uncovered a few bugs in mine at least
08:29:37 <geist> yeah i bet
08:29:43 <lkurusa> soon after, on the Mac there's an app (from dev tools) that can increase your latency and limit bandwidth
08:30:11 <lkurusa> IIRC it could also be used to swap some TCP segments
08:30:20 <lkurusa> so that your out-of-order arrival code could also be tested
08:31:23 <klange> When I finally dragged my old thinkpad out and realized it had a chipset I had functioning drivers for and I managed to actually download a file with my own HTTP fetch tool on my own OS with my own network stack...
08:31:33 <klange> Entirely on baremetal... good feels
08:31:54 <klange> Almost makes the eight years of wasted life worthwhile.
08:32:04 <lkurusa> fantastic yeah
08:32:31 <geist> yah i used to leave a newos vm up and running with the telnet port punched through the firewall for lulz
08:33:20 <bauen1> if i somehow manage to port the linux driver for the ethernet card in my old macbook, i could skip the keyboard for testing :)
09:54:13 <SzateX> Ohh... All i need is triple fault
10:01:32 <SopaXorzTaker> SzateX, this probably won't help, but it's called a "triple fault" too: https://www.youtube.com/watch?v=Nu6QNIxr06I
10:02:26 <SopaXorzTaker> I'm reading an ISO9660 filesystem now. Do directory entries always have a multiple of the sector size as their length?
10:02:29 <SopaXorzTaker> Can I rely on that?
10:06:34 <lkurusa> read the spec ;-)
10:06:54 <lkurusa> i neve really bothered to write a driver for iso9660
10:06:58 <SopaXorzTaker> lkurusa, I can't obtain it :P
10:07:27 <klange> SopaXorzTaker: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf
10:07:53 <SopaXorzTaker> klange, tyvm
10:07:58 * SopaXorzTaker is rtfm
10:08:05 <lkurusa> :D
10:08:36 <SopaXorzTaker> lkurusa, my normal driver development strategy is called Efficient Agile Empirical Driver Implementation Procedure
10:08:59 <SopaXorzTaker> poke at something with a hex editor, find what the data looks like, make assumptions, implement them, look if it works
10:09:38 <SzateX> my driver strategy is called: work please... oh come on
10:09:47 <SopaXorzTaker> Apparently, this approach is used by revolutionary companies such as Microsoft
10:09:48 <SopaXorzTaker> :P
10:10:12 <klange> that's basically how all of toaruos was built
10:10:15 <klange> don't recommend it
10:10:37 <klange> i suggest planning, reading specs, always aiming for correctness...
10:10:46 <klange> you'll hate yourself less in eight years
10:10:52 <SopaXorzTaker> >> The length of a directory shall be the sum of the lengths of all Directory Records in the directory; the number of unused byte positions after the last Directory Record in all Logical Sectors in which the directory is recorded.
10:11:04 <SopaXorzTaker> klange, that was a joke
10:11:08 <SopaXorzTaker> (well, partially)
10:12:00 <SopaXorzTaker> so yeah, according to that it's just the total length of the sectors occupied by the directory
10:12:33 <klange> no i think you're reading that wrong due to poor phrasing
10:12:44 <lkurusa> i prefer reading the spec and then ignoring it
10:12:50 <klange> it's the same of (the lengths of all Directory Records...); (the number of unused bytes...)
10:12:51 <lkurusa> :D
10:12:55 <klange> sum of*
10:13:17 <klange> so your original intuition is correct: this will be a multiple of sector size
10:14:00 <SopaXorzTaker> (= (length-of directory) (+ (length directory-records) (unused-bytes))) -> #t
10:36:45 <SzateX> Has someone know? What are possibilities to crash when enumerating pci?
10:41:21 <bcos_> SzateX: Why are you asking?
10:42:23 <bcos_> (maybe you're worried about something specific, or there's some other reason behind the question)
10:43:22 <SzateX> bcos_, i'm thinking what could go wrong. I'm iterating (i want to be sure i'm do reading good, before change to recursive), reading only 4 registers (taking all 32-bits), and got crashed
10:43:31 <SzateX> with triple_fault
10:44:48 <bcos_> You can safely read from "random" offsets in PCI config space for "random" devices (including offsets and devices that don't exist)
10:45:28 <SzateX> so... problem is in another place
10:45:32 <bcos_> ..so if there's a problem it's likely more to do with (e.g.) "depth first tree search" or what you do with the data you read or..
10:45:50 * bcos_ nods
10:53:33 <geist> you should not be able to triple fault by poking at hardware, so it's almost assuredly a sw bug
10:54:26 <geist> at least not directly. you can theoretically stumble upon something that reconfigures memory or fires an irq you weren't ready for, but that's pretty hard to do
10:54:40 <jove> Setting up a double fault handler should give you some clue what's going wrong.
10:54:47 <geist> yah
10:54:54 <jove> I think a lot of emulators can tell you the source of a triple fault as well.
10:54:59 <geist> and if on an emulator... yeah
10:56:16 <SzateX> oh ok - doing something with tables do triple_fault - repaired
10:58:42 <geist> but, behind every triple fault is usually a pretty fascinating story
11:14:42 <jove> Winter tells a tale / A story of trial and ire / triple fault again
12:09:24 <mrvn> If you have a tripple fault then it's a good time to implement/fix your double fault handler.
12:11:00 <bauen1> if you have a double fault, you most likely have a much bigger problem somewhere
12:12:14 <mrvn> bauen1: depends on how complex your IRQ handler is.
12:13:20 <mrvn> e.g. if you enable IRQs again you can easily stack overflow
12:16:50 <SzateX> irq handler is written by someone other
12:17:57 <mrvn> I can't remember: Does the double fault handler have it's own page tables?
12:18:50 <bauen1> no
12:19:03 <bauen1> so if you overrun the stack or mess up paging you WILL triple fault
12:19:10 <mrvn> Too bad. So no way to recover from a corrupted page table.
12:19:32 <mrvn> bauen1: you can (and must really) set a alternate stack for the double fault handler.
12:19:42 <bauen1> hm
12:20:19 <bauen1> how can you set a seperate stack for a single irq habndler ?
12:20:39 <mrvn> iirc there is a pointer in the TSS
12:39:16 <SzateX> i'm not sure, vbox and qemu doesn't emulate pci or i have an error somewhere. Bochs return me i have one device which is intel uchi usb controller
12:52:15 <klange> SzateX: I assure you, VirtualBox and QEMU emulate PCI ;)
12:52:28 <klange> They would be pretty darn useless if they didn't.
12:52:43 <klange> Your bochs results sound extremely fishy.
12:52:53 <SzateX> klange, so hmm... something goes wrong
12:54:53 <klange> I get a number of devices under a mundane bochs config. https://i.imgur.com/pEPYufa.png
12:59:26 <klange> and a virtualbox for reference https://i.imgur.com/0QGTgzS.png
01:10:03 <SzateX> hmm
01:12:04 <SzateX> https://gist.github.com/SzateX/f3082950d09b10fc09a02219626cba0c and https://gist.github.com/SzateX/762b89765de0d8cfa7c70467d109c292 - okay a do ite by iterating, but now it doesn't matter - if it will work will do recursive scan
06:01:20 <nohop> Anyone ever used the embedded c++ lib "embxx" ? (at: https://github.com/arobenko/embxx )
06:02:04 <nohop> It claims to be a c++ 'standard lib' replacement for bare bones c++. Yes it relies on things like <type_traits>. I don't understand how that could possibly work.
06:23:31 <geist> nohop: does it provide a type_traits implementation?
06:23:56 <geist> i think type_traits in particular is all compile time, so either it comes from the compiler's header or is generally pretty simple
06:25:58 <nohop> That was just an example. It also depends on <functional>, for example.
06:26:33 <nohop> I'm either missing something. Or it's just not really a 'bare bones' library at all.
06:33:41 <nohop> I guess it was meant to be a hosted library on top of existing standard libs. Never mind. Too bad! :)
06:37:45 <Griwes> <type_traits> is freestanding, so everybody should be able to depend on it. <functional>, not so much...
06:45:38 <geist> yeah that sounds like it's not so bare bones
06:45:56 <geist> though it could be that it essentially relies on the header only parts of stdc++ and then provides it's own simpler implementations of things
06:46:06 <geist> we actually implemented essentially our own versino of that for zircon/fuchsia
06:46:43 <geist> fbl, fuchsia base library, is a set of low level intrusive containers and whatnot for use in the kernel and other low level bits
06:47:00 <geist> and type traits is exactly a thing we use out of stdc++
08:04:39 <lsneff> I had an interesting thought earlier:
08:04:53 <lsneff> There's rougly 80-100 billion neurons in the humain brain depending on who you ask
08:05:15 <lsneff> The latency between paired neurons is between 8-14ish milliseconds
08:05:42 <lsneff> I wouldn't put it out of possibility to say that they'll be 100 billion internet-connected devices within the next few decades
08:06:02 <lsneff> and latency between internet-connected devices is roughly 10-100 ms
08:06:20 <lsneff> Interesting, hmmm?
08:07:19 <clever> lsneff: there is a neural-network based soc called spinnaker i think, and they sort of take advantage of that in the design
08:08:12 <clever> lsneff: they have smaller clusters of nodes at the sensors, for low-latency and high bandwidth accesses to the senses (sort of like how the nerves in the retina pre-process the image)
08:08:32 <clever> and then high latency low bandwidth links to the main cluster (like the nerve bundle from the retina to the brain)
08:08:56 <clever> and the main cluster itself is a torus of inter-connected nodes
08:09:32 <clever> https://en.wikipedia.org/wiki/SpiNNaker http://apt.cs.manchester.ac.uk/projects/SpiNNaker/SpiNNchip/
08:09:51 <lsneff> Wow, that's actually quite interesting
08:10:28 <lsneff> 1 million cpus
08:10:37 <clever> lsneff: each die is 18 ARM cores and 128mbyte of sdram
08:10:40 <lsneff> to simulate a billion neurons
08:10:58 <clever> and i think it was optimized to basically do 16bit neurons
08:11:19 <clever> so you just have a table of weights, some inputs, mult, and you have an output
08:11:24 <jove> How are they gonna train it?
08:11:32 <clever> and the entire cluster just goes that in parallel
08:11:55 <jove> I wonder is the simulate interlocking waves with it. That's something most nns don't do.
08:12:31 <lsneff> I really want to see memristors
08:13:04 <lsneff> We would pretty quickly get into millions of simulated neurons on a single die with those.
08:15:00 <jove> We need to do hormones with wifi lol.
08:28:53 <abysslurker> o/
09:07:24 <nohop> I see. I didn't realize <type_traits> didnt' depend on other stuff.
09:20:02 <SzateX> Could someone check what goes wrong? https://gist.github.com/SzateX/f3082950d09b10fc09a02219626cba0c and https://gist.github.com/SzateX/762b89765de0d8cfa7c70467d109c292 - i got 0 devices in QEMU and VBox (4 network adapters + audio adapter) and 1 in Bochs
10:49:02 <SzateX> oh dammit...
10:49:25 <SzateX> stupid error - i forgot to turn on enable bit