Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=9&d=14

Friday, 14 September 2018

12:03:34 <Shockk> is there any chance someone could point me to documentation on the format of the bytes that come from port 0x60 during IRQ1 (for keyboard)?
12:04:49 <klys> shockk, http://bochs.sourceforge.net/techspec/PORTS.LST
12:05:04 <klys> the file is part of Ralf Brown's Interrupt List.
12:07:30 <Shockk> hmm
12:08:25 <Shockk> I'm a bit confused by this code on the wiki https://wiki.osdev.org/PS/2_Keyboard#Enough.2C_give_me_code.21
12:08:27 <bslsk05> ​wiki.osdev.org: PS/2 Keyboard - OSDev Wiki
12:08:36 <Shockk> what's the purpose of it reading from the port twice?
12:11:43 <bcos_> Shockk: I'm trying to figure out where that crap came from..
12:11:48 <Shockk> hahaha
12:12:56 <lachlan_s> Yeah, there is a decent amount of low-quality/broken/bad code on the osdev wiki
12:13:54 <Shockk> any chance someone would be able to speedily clarify it for me? like, in the event of an IRQ #1, do I just read from port 0x60 to get the scancode? or is there more involved?
12:14:00 * bcos_ completely rewrote that whole page, partly to make sure n00bs don't keep failing to separate "PS/2 controller" from "PS/2 device"
12:15:31 <lachlan_s> Back in 2012?
12:15:52 <bcos_> Shockk: Ideally, your PS/2 controller driver gets the byte and forwards it to whichever device driver is attached to "PS/2 port #0"
12:18:12 <Shockk> hmm so where does port 0x60 come into it?
12:18:38 <lachlan_s> That's the i/o port that the keyboard ps2 device attaches to
12:18:45 <Shockk> oh right
12:18:56 <bcos_> No
12:19:06 <lachlan_s> ah
12:19:32 <bcos_> Port 0x60 belongs to the PS/2 controller, and does not belong to any of the PS/2 keyboards, mouses, bar code scanners or whatever else might be talking to the PS/2 controller
12:19:54 * lachlan_s understands
12:28:52 <ALowther> I know there is a list of books on wiki.osdev.org....Do you all have any recommendation on the kind of topics you were just talking about? Hardware interfaces, etc. Like understanding interrupt addresses/vectors, where the bootloader needs to be in memory, etc...I apologize if I am using incorrect terminology as I only know the scattered bits I've gathered online.
12:31:22 <bcos_> ALowther: My recommendation is to choose a specific topic before looking for "everything"
12:31:23 <bcos_> ;-)
12:31:46 <ALowther> bcos_: So those concepts aren't all grouped together? There is a lot that goes into each of those?
12:32:24 <klange> googlebot just hit my gogs instance and this poor little VPS nearly shat itself
12:34:54 <bcos_> ALowther: I'm not even sure how you'd group things like "where the bootloader needs to be in memory (for PC systems with BIOS?)" with things like "hardware interface for NVidia video card"
12:36:12 <bcos_> klange: I think googlebot is relatively polite - e.g. will throttle itself back if it detects it's overpowering a site
12:36:54 <bcos_> (otherwise it'd be like a DDoS attack everywhere it goes.. ;-)
12:38:48 <klange> I was unable to push for two minutes.
12:39:01 <klange> because gogs was busy serving google
12:40:43 <bcos_> Hrm
12:40:48 <bcos_> https://support.google.com/webmasters/answer/48620
12:40:52 <bslsk05> ​support.google.com: Change Googlebot crawl rate - Search Console Help
12:44:34 <ALowther> bcos_: That is a great question...I guess to me, because I've never worked on something low level, where I am accessing raw memory addresses, if I can call them that, it seems that when my computer boots up, I must have specific pieces of information at a specific location because that is where bios will be looking for it, and if it isn't there, then the computer won't boot. So too, if I understand correctly, at a high leve
12:44:34 <ALowther> l, each hardware interface on a motherboard can be accessed via a specific address in memory which I send information to in order to communicate with the hardware....Now after working at this level for a while, it may seem very silly to me to even relate these two in a such a way, but, being where I am in my understanding I relate the two. This very exercise has helped to put more thought into the idea and I will continue t
12:44:34 <ALowther> o dig. Thank you :)
12:49:19 <bcos_> klange: Ah - you might be able to put a "Crawl-delay: .." line in your "robots.txt"
12:49:41 <klange> why are you investigating this
12:50:53 <bcos_> Not sure really - trying to be helpful I guess
12:52:26 <Mutabah> Bored?
12:53:29 <bcos_> A little, yes
12:54:25 <klange> You should test out my current OS image and give me constructive feedback.
12:54:27 <klange> :)
01:00:31 <Mutabah> Huh... freenode server had a sigterm
01:02:00 <bcos_> klange: File browser needs an "up" or "back" button :-)
01:02:23 <klange> yeah, they're unhelpfully squirreled away in the menus...
01:03:05 <klange> ugh what, the python version had a context menu and I apparently haven't implemented that in the NIH C version
01:17:23 <bcos_> Grr - #osdev is +r
01:17:42 <bcos_> klange: IRC client doesn't seem to handle cursor keys well..
01:18:17 <Mutabah> Hmm... do you know if the spam attack has abated?
01:19:33 <klange> oh yeah that irc client is a thing... that needs a major update
01:19:42 <klange> I can build an IRC client based on... my text editor...
01:20:05 <bcos_> Mutabah: Not sure :-)
01:20:33 <lachlan_s> Ugh, I ordered 3.5mm bullet connectors and received 3mm
01:20:38 <Mutabah> Let's find ount!
01:20:44 <klange> RIP #osdev
01:21:10 <bcos_> klange: I was suprised networking just plain worked (didn't even realise I told virtualbox to have a NIC until I clicked on the "network status" icon at top of GUI)
01:21:27 <klange> yeah it gives you one by default
01:21:42 <klange> sets it up with slirp nat
01:22:37 <toaru-user> Heh :-)
01:22:41 <klange> that irc client needs a lot of work
01:22:45 <toaru-user> [A[A[A[A[A[A[A
01:22:48 <toaru-user> [C[C[C[C[C[C[C
01:22:49 <klange> as you can see
01:22:51 <Mutabah> AAAAAAA!
01:22:52 <klange> please stop :O
01:23:25 <klange> the curses one was slightly better I think
01:24:33 <toaru-user> cat /dev/cpuinfo looks a little minimal
01:27:03 <toaru-user> ("/proc" I mean)[D[D[D[D[D[D[D[D[D[C[C[C[C[C[C[C[C[
01:27:30 <klange> you should probably stop using the irc client, you seem incapable of preventing yourself from hitting cursor keys :)
01:27:42 <bcos_> That was the delete key :-)
01:27:55 <bcos_> ..or backspace
01:28:02 <Mutabah> Not left cursor?
01:28:12 <klange> backspace should work? that looks like left and right cursor
01:28:40 <toaru-user> test[3~[3~[3~[3~[3~[3~[3~
01:28:41 <klange> I should hack in this fancy new line editor, but I need to make some adjustments so it can read from the IRC socket at the same time...
01:28:47 <klange> now *that's* the delete key.
01:29:10 <bcos_> Ah - I tried to "cursor left" then delete from the middle
01:31:00 <klange> uh, actually, the irc client seems to be completely fucked on my current build
01:31:44 <klange> bcos_: where did you get the image you're running?
01:32:08 <bcos_> It's the nightly build from gihub I think
01:32:24 <bcos_> *github, or maybe gitlab?
01:32:43 <klange> neither of those do nightly builds
01:33:39 <klange-toaru> I think I fixed it. Miiinor buffer issue - and I see the problem with the cursor keys, it's just dumping the escape into the buffer
01:33:56 <klange-toaru> basically the irc client completely lacks a line editor... it supports backspace
01:34:25 <klange> I'll work on that, but it's a low priorty app.
01:34:58 <bcos_> Ah - the link on gitlab is "toaruos.org/nih.iso"
01:35:18 <klange> Interesting, that build's IRC client should be completely broken
01:35:39 <klange> should have been spewing crap from an uninitialized buffer instead of drawing the message entry bar :)
01:35:54 <toaru-user> It seems to work sort of & was the only thing I could find that uses networking (no ping, traceroute, ...)
01:36:09 <klange> `fetch` for a wget/curl-alike
01:36:57 <bcos_> Hrm - I can't get "help" to work
01:37:22 <Shockk> hm oh wait, I may have been mixing things up in my head
01:37:34 <klange> bcos_: clarify what you mean by that?
01:37:48 <Shockk> bcos_: keyboard input needs to be read via PS/2 right? not via PIC?
01:38:09 <bcos_> "tab tab" lists available utilities (it's how I found the IRC client) and it lists a "help", but I can't seem to start that from console
01:38:20 <Mutabah> Shockk: You read from the PS/2 controller's io port when there's an interrupt
01:38:26 <klange> help is a shell built in?
01:38:36 <klange> what does it do when you run it?
01:38:37 <klange> screenshot?
01:38:40 <Shockk> Mutabah: ah right
01:39:24 <Shockk> wait, the PS/2 controller, or the PS/2 keyboard device itself?@
01:39:39 <bcos_> klange: Ah - I see - it is showing help for the shell. I was trying to do "help fetch" like it was "man fetch" on *nix
01:40:51 <Shockk> ah wait, I see that the same data port is used for both devices and the controller itself
01:41:22 <Mutabah> Shockk: The controller's main data port is usually 'mapped' to the FIFO
01:41:24 <klange> fetch should show help when given no args, and I tend to stick help on -? because it's what getopt is supposed to return on an unrecognized option
01:42:22 <klange> ugh fetch has an -h arg, it shouldn't do that
01:43:35 <klange> oh, well, fetch -h still gives you help output, so I guess it's fine since it's just a flag...
01:45:34 <bcos_> Heh - "fetch http://toaruos.org/nih.iso" sends the data to stdout - oops :-)
01:46:07 <klange> yeah, more curl-alike than wget-alike...
01:46:14 <bcos_> - no way to create partitions or format a file system, and can't write a file to read only CD
01:46:32 <klange> the whole root is a r/w tmpfs though
01:46:43 <klange> but yeah, needs some partition tools for an installer
02:01:46 <bcos_> klange: Task bar at top of GUI gets a little messed up if you start too many apps..
02:02:04 <bcos_> klange: Scheduler is round robin?
02:02:46 * bcos_ started about 40 plasma demos to see how it handles CPU load.. ;-)
02:03:02 <klange> plasma's a great CPU burner
02:03:53 <klange> oh snap it just go booms, I thought I had the smaller icons implemented...
02:04:11 * klange tickets
02:06:42 <bcos_> "ps -?" doesn't tell you much about the "[format]" part - not sure if there's a way to get CPU usage of each thread
02:07:32 <klange> there is not, sorry
02:07:46 <klange> i should probably get that in there...
02:07:50 <bcos_> I think it just ignores the format?
02:08:16 <klange> it doesn't, but it also only really implements a couple of format chars
02:08:35 <bcos_> Hrm - no error for bad format
02:09:24 <klange> it supports 'a' for showing the whole commandline and 'u' for... doing that and showing the username? it's a really mediocre `ps` because the kernel doesn't provide a lot more
02:09:33 <klange> I can probably hack in memory usage easily enough...
02:09:53 <klange> but the CPU usage stuff isn't even implemented yet >_>
02:13:09 <Shockk> hmm I have a question
02:13:11 * bcos_ can't guess root user password for sudo
02:13:26 <klange> sudo is your user's password, which is `local`
02:13:51 <bcos_> Ah - cool :-)
02:14:13 <Shockk> if I'm going to be sending a command to the PS/2 keyboard after receiving an IRQ1, do I not need to worry about sending bytes out-of-order to the port?
02:14:17 <klange> ... that used to be on the boot screen when I still used grub...
02:14:32 <Shockk> i.e. what if the interrupt came in while something was in the middle of sending bytes?
02:16:01 <bcos_> klange: Hrm - "sudo /etc/master.passwd" shows that the passwords are stored in plain text - not hashed or anything..
02:16:12 <bcos_> *sudo cat
02:17:09 <bcos_> Shockk: You can only send 1 byte at a time, and the device should buffer them internally until it gets enough to act on
02:17:50 <klange> bcos_: I was just in the middle of typing "there isn't a crypt or hashing implementation in this build so fun fact..."
02:18:00 <bcos_> :-)
02:18:12 <Shockk> bcos_: well what I mean is, what if something sends the command byte 0xED to the keyboard, which should be followed by a data byte,
02:18:40 <Shockk> but immediately after the instruction that sends that command byte, the interrupt goes through
02:19:10 <Shockk> in this case, if I send a command to get the current scan code, then won't it be interpreted as the data byte for the 0xED command?
02:19:41 <bcos_> Shockk: It's not RAM - reads go to one register, writes go to a different register
02:20:13 <bcos_> ..so write will go to "output buffer" and read will read from "input buffer"
02:20:15 <Shockk> yes but sending the command byte to get the scan code is a write, isn't it?
02:20:34 <bcos_> There's no command to get the scan code - you just "in al,0x60"
02:20:50 <Shockk> hmm wait
02:20:50 <bcos_> (assuming there's a byte in the input buffer)
02:20:59 <Shockk> oh the description on the wiki is slightly bad
02:21:08 <Shockk> it lists command 0xF0 as "Get/set current scan code"
02:21:25 <Shockk> okay that simplifies things then
02:21:37 <bcos_> Hrm - that probably should be "get/set current scan code set"
02:22:17 <Shockk> right; I mean it includes the word "set" in the sub-command table, but I looked at the description
02:23:32 * Shockk is your friendly neighborhood wiki clarification discoverer
02:23:58 <bcos_> Fixed :-)
02:24:06 <Shockk> nice, thanks
02:24:12 * bcos_ has to make some lunch - back in ~20 minutes
04:13:54 <bcos_> klange: Heh - made it crash during boot by only giving the virtual machine 32 MiB of RAM - no "does enough memory exist" sanity check. Seems to crash in protected mode (after "loading ramdisk...") with paging disabled and IDT left set to BIOS defaults (base = 0, limit = 0x3FF) so no exception handlers either. Caused VirtualBox to go into "Guru mediation"
04:14:35 <klange> that'll be the bootloader's fault
04:14:48 <klange> good point
04:15:08 <bcos_> At 64 MiB the GUI shows a red "Out of Memory" message on a black screen :-)
04:15:39 <klange> that's the kernel framebuffer fatal error screen
04:16:21 <klange> it's, uh, inspired by the "wasted" screen in GTA
04:17:00 <bcos_> Hrm - at 96 MiB I get red "out of memory" on a grey background with "faded to black" edges
04:17:38 <klange> isn't it just the best error screen?
04:18:26 <bcos_> Ooooh..
04:18:34 <klange> my last bit of instrumentation says the UI at 1440x900 wants about 128MB minimum just to load
04:19:06 <klange> you can lower that requirement a bit with a hard disk install, but those canvases take a lot of space :(
04:19:47 <bcos_> At 128 MiB it worked, so I started a few plasma demos and they worked, and then I resized the virtualbox window and it got "out of memory" on a mostly black screen with corruption (horizontally stretched random black/grey/white bars)
04:20:21 <klange> that sounds like it ran out of RAM in the middle of trying to adjust the display resolution
04:20:25 <klange> :D
04:20:26 * bcos_ nods
04:21:28 <klange> I think I got a hard disk boot to work in VGA text mode on as little as 16MB, which is pretty good for how willy-nilly I am with allocating memory for shit
04:21:51 <bcos_> Fortunately (unfortunately?) I can't stretch a real monitor like that ;-)
04:22:19 <bcos_> I got stuck at login prompt for VGA text mode boot
04:23:36 * klange taps foot waiting for cacheless boot
04:23:45 <klange> 14MB
04:24:37 <klange> $ free -ut → 14 MB / 15 MB
04:24:44 <klange> amazed that works
04:27:55 <bcos_> Hrm- broke it again - this time whole screen full of vertical coloured stripes
04:28:49 <bcos_> ..VirtualBox with ~2.8 GiB of RAM, but with the ICH9 chipset instead of the PIIX3
04:29:33 <klange> Yeah, I think I've got PCI issues with the ICH9. I need to investigate that further.
04:31:30 <klange> oh wow that seems to be... failing to actually switch video modes, but it seems oblivious to the fact that it failed?
04:31:52 <klange> and /proc/pci is empty
04:32:14 <bcos_> I'm wondering if it set the video mode but got 24-bpp instead of 32-bpp or something
04:32:25 <klange> looks like it's still text mode to me
04:32:46 <klange> vga text mode gets to a shell, and `/proc/pci` is empty
04:32:50 <klange> very fun!
04:34:54 <klange> oh I think I know what's happening in the graphical case
04:35:49 <klange> video autodetect failed to detect anything, assumed it was in a preset mode, used the garbage fire hack to find the higher display memory and then just went on writting, blissfully unaware of the fact that it's still in text mode
04:38:20 <klange> yep, that's what happened; if I change the boot command line to force qemu it manages to set up video without PCI; so I need to figure out why I'm not getting PCI out of the ICH9 :)
04:39:18 <bcos_> klange: For me, it's not in text mode - looks like maybe 800*600
04:39:32 <klange> You set up for EFI?
04:39:46 <bcos_> No, not yet :-)
04:41:56 <bcos_> Ah - works nice with EFI and PIX3, but I do get text mode (instead of corrupt graphics) for ICH9
04:50:01 <bcos_> klange: Tried most combination of settings I could - didn't find any other way to cause problems (even worked fine with a bizarre "31 port" SATA/AHCI controller) :-)
04:51:22 <bcos_> D'oh. VirtualBox firmware won't boot from a USB CD drive
04:51:34 <klange> qq
04:52:45 <bcos_> Yay - SCSI CD drive causes black screen after boot menu :-)
04:54:00 <klange> BIOS loader needs an IDE CD drive, EFI loader shouldn't care, but it depends on whether the EFI firmware works
04:56:09 <geist> yah whether or not a real scsi controller and/or cd drive has EFI drivers
04:56:12 <bcos_> Needs a "failed to find the drive" error message.. ;-)
04:56:24 <geist> or if the EFI driver set find a scsi cdrom is unknown
04:56:45 <geist> i guess i actually have a tes case: i have a relatively modern AMD machine with plain old PCI slot, and i have one or more old scsi cards
04:57:01 <geist> but i'm gonna take bets that it doesn't work because the old scsi cards are way pre EFI, so they dont have efi drivers on board
04:57:13 <geist> and the EFI impementation on the motherboard almost certainly doesn't have scsi chipset support
04:57:36 <zid> Right done dying to artorias in dark souls.. I should probably add a bitmap to my 2M/4k allocator I wrote
04:57:40 <zid> and actually start using the damn thing
04:58:00 <bcos_> klange: Um, USB tablet (instead of PS/2 mouse) works perfectly but there's no IRQ for any USB controller?
04:59:04 <bcos_> Hrm - maybe your virtualbox "guest additions" bypasses the actual hardware
04:59:11 <klange> bcos_: 100% certain with the vbox cursor driver you're not actually getting the USB tablet
04:59:41 <klange> there's also a vmware+qemu driver, which is why I can use qemu's VNC backend without USB
05:02:43 * bcos_ can't think of any more ways to try to break stuff :-(
05:03:27 <zid> spam a usb event every mcirosecond
05:03:36 <klange> that will do literally nothing with no USB driver :)
05:03:39 <zid> while allocating memory in 16 threads
05:03:43 <zid> klange: I found a bug.
05:03:46 <zid> You have no USB driver.
05:03:50 <klange> that's not a bug
05:03:55 <klange> it's a lack of a feature!
05:04:42 <bcos_> Hrm, there's python if anyone remembers the language (might be able to "fork bomb")
05:05:21 <zid> Run it OOM and see if it all explodes, good idea
05:05:23 <klange> "if anyone remembers the language" Python is actually is actually the top language according to IEEE's latest study https://spectrum.ieee.org/at-work/innovation/the-2018-top-programming-languages
05:05:24 <bslsk05> ​spectrum.ieee.org: The 2018 Top Programming Languages - IEEE Spectrum
05:05:39 <zid> klange: erm.. re-read that?
05:05:46 <klange> minus one "is actually"
05:05:59 * bcos_ hasn't touched python since Uni - all I remember is "whitespace and no semicolons" :-)
05:05:59 <zid> If anyone *remembers enough python to write a fork bomb*, is a good reading of it, for example
05:06:16 <klange> that is not what bcos_ said
05:06:53 <zid> That was authoritive, did you ask him?
05:07:04 <bcos_> klange: Is there a text editor?
05:07:16 <zid> That's how I read it, why am I not allowed to be authoritive about that being the reading? (It's also backed up by his comment of saying he only remembers it needs whitespace)
05:07:38 <klange> bcos_: bim is quite complete (just avoid loading binaries, it may barf on them)
05:08:08 <klange> I did just spend the past month constantly spamming this channel with my bim development progress
05:13:29 <bcos_> Heh, bim isn't going to be compatible with me - will try creating some python and "fetching" from my web server :-)
05:13:40 <klange> Not a fan of vim-likes?
05:14:08 <klange> I could bang up a non-modal... mode.
05:14:09 <bcos_> I walked out of a uni degree because they expected me to use vim
05:16:03 <klange> I support arrow keys and mouse. I could add some key binds to save from insert mode.
05:16:10 <bcos_> ..then went to a different uni ~10 years later, and it was all java and www and stuff
05:20:44 <zid> Okay so the only thing I have left to do is figure out how the fuck to get this bitmap page mapped into memory I guess
05:21:32 <zid> Let's hope the allocator is catch-22-proof enough to have it work to map itself
05:23:26 <bcos_> Yay!
05:23:51 <zid> I can run the init function under the bootloader's identity mapping to get it initialized, then the init from the kernel side should just need to map the bitmap pages and it should all work.. in theory
05:23:55 <bcos_> klange: Python fork bomb leads to GUI being unable to respond breifly, then "out of memory" red text on black background
05:24:02 <klange> :O
05:24:04 <klange> ;)
05:24:04 <bcos_> :-)
05:24:33 <bcos_> Awesome high qulity code: http://bcos.hopto.org/bork.py
05:26:14 <zid> why the fuck did I try to run that? :P
05:26:34 <zid> "oh a link *click*" "Oh it's asking if I want to open it, sure why not"
05:26:36 <klange> honestly i consider it an accomplishment that I can run this python fork bomb :)
05:27:12 <Mutabah> zid: 'grats
05:27:23 <zid> I haven't actually done it yet, don't fire those off just yet :P
05:27:54 <zid> currently it's just a windows program with the wrong pointer size on my desktop, got to 'port' it to my OS
06:47:28 <klys> mutabah, eyy
07:01:25 <zid> bcos_: https://gist.github.com/zid/8cb363de27e821904002c6ccd8682fa1 Version 0.1, no free() yet
07:01:27 <bslsk05> ​gist.github.com: .c · GitHub
08:45:37 <Pichet__> Alⅼɑһ іs doіᥒɡ
08:45:40 <Pichet__> sun іs ᥒot ԁoiᥒɡ Аlⅼah іѕ doiᥒɡ
08:45:42 <Pichet__> ⅿοoᥒ is nഠt ԁoiᥒg Alⅼah іs ԁоіᥒɡ
08:45:45 <Pichet__> starѕ arᥱ not dοiᥒɡ Allaһ іѕ ԁoinɡ
08:45:47 <Pichet__> рlɑᥒets arе not ԁoinɡ Aⅼⅼɑh is ԁoⅰᥒɡ
08:45:50 <Pichet__> ɡalaxieѕ ɑrᥱ ᥒοt dоiᥒg Alⅼah is dοiᥒɡ
08:45:53 <Pichet__> осeaᥒѕ ɑrе nⲟt ⅾoing Αⅼlah іѕ ⅾⲟⅰᥒg
08:45:55 <Pichet__> mοᥙᥒtaiᥒs аre not dഠіᥒg Allɑh iѕ doiᥒg
08:45:58 <Pichet__> treеs аrе nⲟt ԁoiᥒɡ Aⅼlah iѕ ⅾⲟiᥒg
08:51:58 <zid> oh wow that guy is still going?
08:52:08 <zid> I've been seeing that same spam for at least 2 years
08:55:15 <vdamewood> I've only seen it in the last month or so.
08:59:39 <zid> I have logs from 2016 of it
09:01:06 <zid> vdamewood add free() for me while I am asleep, k?
09:01:28 <zid> I was too lazy to do it today
09:01:40 <vdamewood> huh?
09:01:47 <zid> You heard me!
09:02:14 <vdamewood> free(zid)
09:02:16 <vdamewood> ;
09:02:39 <zid> You gott do the bit between the braces, not just call it :P
09:02:55 <vdamewood> void free(void* foo) { }
09:03:10 <zid> hey who told you my current implementation!
09:03:24 <vdamewood> zid: Have you seen my implementation of malloc?
09:03:28 <zid> someone has been leaking my top secret code
09:03:29 <zid> I have not
09:03:33 <zid> is it page += 4096
09:03:54 <vdamewood> void *malloc(size_t sz) { return (void*)rand(); }
09:04:02 <zid> ah yes, bogomalloc
09:04:15 <zid> Just assume you have infinite ram and it never produces collisions
09:04:29 <vdamewood> It's guaranteed to work at least once.
09:04:39 <zid> if rand is an LCGR then it would work once for every page of memory
09:05:55 <vdamewood> Naw, i have my implementation of rand plugged into a geiger counter.
09:06:10 <zid> I recommend 1664525 and 1013904223
09:06:31 <vdamewood> But those are two entirely different numbers.
09:06:38 <zid> or you could go for the classic glic type_0 of 1103515245 and 12345
09:07:00 <zid> It's surprising how often that one pops up
09:07:10 <zid> A whole bunch of gameboy advance games etc
09:10:45 <vdamewood> I forget, was the GBA ARM based?
09:10:57 <zid> arm7tdmi
09:11:07 <zid> NDS is an arm7tdmi and an ARM9
09:11:44 <zid> gc/wii is some ppc thing
09:12:05 <vdamewood> Yeah, so was the PS3.
09:12:19 <zid> ps3 was a super weird custom ppc thing with vector units and crap though
09:12:24 <vdamewood> While the PS4 and XBone are both AMD64.
09:12:39 <zid> xbox was supposed to be a pentium 3 and ended up being some amd chip or something afaik
09:13:10 <zid> or the other way around, they had different behavior re wraparound at the end of memory and caused an exploit :D
09:13:33 <vdamewood> Yeah, I think the X Box did end up with a Pentium 3.
09:13:52 <zid> The xbox security talk is amazing
09:13:55 <vdamewood> And it was something like 733 MHz, or something.
09:13:59 <zid> I should rewatch it it has been a while
09:14:28 <zid> The original wii attack was just dumb, effective but dumb
09:16:07 <vdamewood> I still remember back when Vista came out my class mates and I would crash peoples' systems using a CIFS bug.
09:16:31 <zid> Does w10 crash if you try to access COM:// or is that dead? :P
09:16:44 <vdamewood> I haven't heard anything about it.
09:16:47 <zid> that'd hardlock you up to like w2k
09:20:34 <mischief> does anyone happen to know how large pax extended headers can be?
09:20:42 <mischief> can they be larger than one block?
09:21:00 <zid> I don't even know what pax is, rip
09:22:52 <mischief> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
09:22:55 <bslsk05> ​pubs.opengroup.org: pax
09:25:13 <vdamewood> zid: Short answer: POSIX doesn't do tar, but instead has its own archiver and utility that only Apple seems to use.
09:26:16 <vdamewood> Oh wait, that was xar that Apple uses, I think.
09:27:11 <mischief> i initially thought about just tossing pax headers but i'm looking into reading long file names.
09:27:27 <mischief> i could be cheap and assume they aren't larger than a block..
09:30:33 <vdamewood> mischief: Did you read the extended description section of that page?
09:30:47 <mischief> it doesn't seem to specify a maximum.
09:31:20 <mischief> it just says that a stringified decimal length exists for the extended attribute value
09:31:33 <mischief> maybe it's a bignum!
09:32:33 <vdamewood> mischief: "An optional header block with extended header records." <-- I'd say zero or one.
09:34:09 <mischief> hm
09:34:28 <mischief> gnu tar manual says posix format can store 'unlimited' file name length
09:35:04 <vdamewood> I think this is as far as I can help without actually learning the format myself.
09:35:12 <vdamewood> I think I'm too lazy to do that at the moment.
09:47:41 <mischief> ok.
09:47:47 <mischief> the file names just span blocks.
09:50:23 <Guest99108> Аllaһ ⅰѕ ⅾoіnɡ
09:50:26 <Guest99108> suᥒ is nഠt doiᥒg Αlⅼah is ⅾοіᥒg
09:50:29 <Guest99108> mοοᥒ is not dⲟіng Allɑh іs ⅾοіng
09:50:31 <Guest99108> stаrs ɑrе not ԁoiᥒg Ꭺllɑһ іs doing
09:50:36 <Guest99108> рlanetѕ arᥱ ᥒot doіng Αlⅼɑh іs ԁоiᥒɡ
09:50:43 <Mutabah> *sigh*
09:50:50 <Mutabah> Ok, so that was seven hours
10:10:03 <ybden> oh wow they're back
10:10:15 <ybden> not seen that in ages
10:10:18 <Mutabah> Well, I cleared +r this morning
10:10:35 <ybden> unsure whether that's actually the original guy
10:10:41 <Mutabah> 09:20 -!- mode/#osdev [-r] by Mutabah
10:10:53 <Mutabah> 17:50 -!- Guest99108 [~Standbye@61.72.150.202] has joined #osdev
10:11:03 <Mutabah> 8.5 hours, interesting
10:11:34 <asymptotically> it's a lot less frequent than it was, but it hasn't really stopped
10:21:26 <moymoy23> Αllɑһ iѕ doinɡ
10:21:49 <Mutabah> yeah... I'm putting +r back
10:21:57 <Khaotic> lol
10:22:00 <Khaotic> op me!
10:25:22 <sham1> Morning (UGT)
12:12:55 <klange> added some memory info to my /proc/*/status and `ps`
12:46:00 <klange> a nice bonus of this new line editor is that scrolling throw history doesn't erase my clock
12:46:38 <sham1> What's the point of having a clock on the current shell line
12:46:55 <klange> tells you when the last command completed, which can be useful for a few reasons
12:47:05 <sham1> Ah
12:47:06 <sham1> True
12:47:16 <klange> sometimes I'll hit enter to get a fresh prompt with an updated clock just before running a command
12:48:06 <lkurusa> it was useful to me when i forgot about a command to see just how much time i lost reading stuff
12:48:19 <lkurusa> nowadays i replaced that with the 'done' plugin for fish shell
12:48:29 <lkurusa> (automatic notifications after long running commands ftw)
12:49:20 <klange> I apparently haven't brought back my toast daemon yet...
12:49:48 <sham1> Does your toast daemon use its own thing or do you have dbus ported
12:49:57 <klange> it's its own thing, there's no dbus here
12:50:02 <sham1> Ok
12:50:06 <sham1> Makes sense
12:51:54 <klange> I ported it to Python, so I'll have to dig through git history to find the old C version if I want to blow the dust off it and get it running again
12:52:16 <klange> The python version had some nice features because it used my fancy text layout engine
12:52:31 <klange> so you could spit out toasts with emoji and images
12:53:15 <klange> I still need to port that to C, but it really abused garbage collection
01:27:54 <klange> nice, fixed some super slow text selection in my terminal...
02:40:15 <lachlan_s> Okay, my vga textbuffer driver stopped working, so I think the physical mapping is just broken
02:42:27 <lachlan_s> Probably why the e1000 driver isn't working either
02:56:24 <MarcinWieczorek> Hello, I'm looking for some writeups regarding VFS buffer cache, do you guys have any interesting links?
04:48:32 * geist yawns
04:49:15 <blackandblue> hi geist
04:49:33 <blackandblue> whats the plan for weekend. anything cool happening?
04:53:26 <geist> not yet, no
04:53:33 <geist> haven't thought that far forward yet
04:53:52 <geist> i usually wake up saturday and then think about what to do
04:54:07 <zid> I don't even bother waking up
04:59:41 <_mjg> you just gave away that you go to sleep in the first place
05:00:39 <FireFly> I'm definitely planning on sleeping... I think I've had too little of that this past week
05:01:01 <_mjg> don't sleep, start rewriting your code
05:01:07 <_mjg> best results
05:01:21 <geist> yah sadly the no sleep thing doesn't work for me anymore
05:01:29 <_mjg> :)
05:01:34 <geist> energy drinks no longer replace sleep
05:01:47 <_mjg> ye, i dropped those years ago
05:01:53 <FireFly> I never did that to start with, I try to care a bit about my body :p
05:02:07 <_mjg> FireFly: i can see you not sitting straight from here
05:02:12 <FireFly> ...point
05:04:07 <sham1> If you aren't crouched over your computer you are not enthusiastic enough
05:05:18 <blackandblue> laptops help, you can use them while on bed
05:05:24 <blackandblue> PC suck in that regards
05:05:31 <_mjg> watch me
05:07:33 <zid> _mjg: I am a highly experienced sleeper
05:07:42 <zid> blackandblue: I'm on a bed with a PC :P
05:07:52 <zid> monitor turns 90 degrees, keyboard comes off the desk
05:08:11 <blackandblue> lol
05:08:20 <blackandblue> you are experienced
05:08:44 <zid> only problem is falling asleep with keyboards and mice and stuff all over your bed and destroying them in your sleep
05:08:58 <blackandblue> yup
05:08:58 <sham1> And them clicking when you turn your head
05:09:03 <blackandblue> lol
05:09:13 <zid> I accidentally wiped my browser's settings in my sleep once
05:10:19 <sham1> :D
06:00:59 <rakesh4545> hello people
06:01:55 <rakesh4545> I am trying to call a C kernel from a bootloader written in assembly (NASM) but it ain't working.
06:02:09 <zid> call main
06:03:30 <rakesh4545> in my boot loader program i am calling a memory address 0x8000 and linking my C kernel such that it starts at 0x8000 but still it won't work
06:03:41 <zid> is it loaded there?
06:04:18 <zid> (also this is going to take forever if I have to ask you every possible question first, you might want to make a gist.github.com link with a bunch of info or something)
06:04:20 <rakesh4545> https://stackoverflow.com/questions/27051471/call-c-kernel-from-assembly-bootloader# My problem is this this post only it is not working for me.
06:04:23 <bslsk05> ​stackoverflow.com: Call C kernel from assembly bootloader - Stack Overflow
06:04:49 <zid> rakesh4545: That is.. not valid C
06:04:54 <zid> "X" is not compatible with char
06:05:17 <MarcinWieczorek> zid: it's not his code
06:07:15 <MarcinWieczorek> rakesh4545: load a kernel entry that does "call main" at 0x8000 and jump there from the bootloader, that's all
06:07:17 <zid> I'll ust wait for the real question then
06:07:34 <MarcinWieczorek> zid: true
06:11:13 <rakesh4545> <MarcinWieczorek> My problem is the call to 0x8000 seem to send the excution at an invalid address.
06:11:34 <rakesh4545> *memory
06:13:44 <rakesh4545> and because of that the emulation crashes.
06:13:59 <MarcinWieczorek> rakesh4545: what are using for emulation?
06:14:10 <rakesh4545> qemu
06:15:06 <MarcinWieczorek> rakesh4545: make sure there is code there
06:15:08 <MarcinWieczorek> pmemsave
06:15:11 <geist> then stop the emulation and see what's there
06:16:34 <rakesh4545> ok I will report after I try.
06:16:43 <MarcinWieczorek> you can just hlt just before the jump and do pmemsave
06:16:50 <geist> yah that's what i'd do
06:16:59 <geist> or just break into the console and see what is where
06:17:09 <geist> a jmp to . right before the branch should also work
06:17:27 <MarcinWieczorek> geist: yeah but he'd need to stop it from crashing ;)
06:17:37 <MarcinWieczorek> if he doesn't JMP $ or something
06:17:51 <geist> that's what i mean. put a hlt or jmp right before it
06:17:54 <geist> and then break into it
06:19:01 <graphitemaster> I trigger a bochs breakpoint ala 8A00 + 8AEO
06:19:12 <geist> they're using qemu
06:19:17 <graphitemaster> qemu supports that
06:19:37 <geist> then it's a qemu breakpoint
06:19:46 <MarcinWieczorek> right
06:19:55 <graphitemaster> well bochs did it first, qemu copied it
06:20:04 <geist> but honestly an infinite loop is the simplest
06:20:11 <geist> requires no intervention of the emulator
06:21:01 <geist> the next question i'm sure will be some variant of 'how do i get the state of the cpu'
06:21:43 <MarcinWieczorek> geist: I think we gave some hints already
06:21:55 <geist> indeed
06:22:02 <rakesh4545> No the next question is I am unable to figure how to pmemsave :(
06:22:20 <geist> yah dont do that yet. if you have the command line of qemu you can inspect the state of the cpu
06:22:23 <MarcinWieczorek> rakesh4545: view -> console -> help pmemsave
06:22:28 <geist> and directly look at memory with x or xp
06:22:46 <geist> so you can basically xp /32 0x8000 or whatnot to see what's there
06:38:41 <rakesh4545> https://i.imgur.com/RGuujK2.png
06:38:51 <rakesh4545> this is what I have
06:38:59 <geist> so what does that tell you?
06:40:17 <rakesh4545> nop!
06:40:29 <rakesh4545> no instaruction or data
06:40:34 <geist> right
06:40:40 <rakesh4545> *instruction
06:41:49 <rakesh4545> I should try with a linker script next.
06:42:28 <geist> you should debug why the loader isn't putting it there
06:42:45 <geist> fiddling with the linker script presumes you know the reason why
06:42:56 <geist> step one is debug the problem
06:44:03 <rakesh4545> at one point as mentioned in https://stackoverflow.com/questions/27051471/call-c-kernel-from-assembly-bootloader# I am concatenating the two binary files. I think thats where the problem originates.
06:44:30 <geist> debug it
06:44:49 <geist> dont guess at the answer, figure it out definitively and then solve it
06:45:19 <rakesh4545> guide me
06:46:15 <geist> sorry, i'm a bit busy at the moment
06:46:28 <rakesh4545> no problem
06:46:33 <graphitemaster> we help those who help themselves
06:47:12 <rakesh4545> ok i understand
06:47:44 <zid> graphitemaster: Or rather, there's helping, and then there's "doing it for them"
06:47:52 <zid> The latter is called a job :p
06:48:29 <geist> yah i'm not trying to be an ass. i'm (in a not very good fashion) trying to point you at tools to solve it yourself
06:48:33 <geist> you'll learn far more that way
06:48:49 <geist> but i'm also doing like 3 things at once so i'm not being very good at being present
06:49:07 <bauen1> geist: buy another brain to help you
09:58:41 <mauz555> how to compile GCC without stdlibc ?
10:01:21 <zid> -s0 for crossdev
10:01:37 <zid> consult your build environment
10:11:48 <MarcinWieczorek> nostdlib, ffreestanding
10:12:10 <zid> Those are flags for gcc
10:12:24 <zid> neither will work to compile gcc without glibc
10:13:45 <heat> first you have to picka bare metal target
10:13:50 <heat> pick a*
10:14:07 <heat> then you have to pass -without-headers as a configure option
10:15:05 <heat> and that should be it
10:36:51 <ohhithere> hi, Does anyone know what happens when the cpu resumes from halt? i mean, on a machine with HTT enabled, when you HLT, the logical processor enters C1 and other threads are still running on the cpu, the manuals states that when some specific types of exceptions/interrupts/signals occur, the cpu will resume to the next instruction after HLT. who performs this context-switch, is it the cpu doing it by itself or jumping to some OS inte
10:37:02 <ohhithere> what happens to the faulting thread (say it was a bp exception)? also, i get the other reasons but why would the cpu want to wake when theres a debug exception?
10:38:19 <heat> it's the cpu
10:38:48 <bcos_> HLT makes CPU wait until an external event happens (IRQ, NMI, machine check, SMI) and doesn't/can't be woken by normal exceptions (breakpoint, etc)
10:38:51 <heat> and when you don't want to be woken up you usually just mask interrupts
10:39:03 <heat> (through cli in x86)
10:39:50 <ohhithere> bcos_: the manuals states that debug exceptions will wake up cpu from HLT
10:40:18 <bcos_> How?
10:40:25 <ohhithere> heat: so the faulting thread waits? gets switched to other cpu?
10:40:33 <bcos_> When CPU isn't executing anything, how does it trigger a debug exception?
10:40:44 <ohhithere> bcos_: in C1 state
10:41:11 <ohhithere> in hyper threading cpu, when you HLT, the entire CPU isnt "sleeping/waiting", just the logical core.
10:41:19 <heat> and?
10:41:22 <ohhithere> the cpu keeps on executing different threads
10:41:44 <heat> If you have hyper threading you usually have 2 threads per core, when both of them are in HLT, the core is HLTed itself
10:41:46 <heat> simple
10:42:06 <ohhithere> i am also trying to understand why would they want to wake the cpu on debug exceptions
10:42:12 <bcos_> ..and when only one logical CPU is in HLT, the core is not in C1 - it's being used by the other logical CPU
10:42:40 <heat> when an external interrupt is routed to a specific thread, it wakes up the thread and/or the core
10:42:43 <ohhithere> bcos_: and when that other logical cpu causes a bp exception?
10:42:49 <heat> no.
10:43:03 <heat> individual threads are treated as separate CPUs
10:43:22 <heat> they don't share anything except execution time on a core
10:43:31 <ohhithere> so what did intel mean by "An enabled interrupt (including NMI and SMI), a debug exception, the BINIT# signal, the INIT# signal, or the RESET# signal will resume execution. If an interrupt (including NMI) is used to resume execution after a HLT instruction, the saved instruction pointer (CS:EIP) points to the instruction following the HLT instruction." ?
10:43:32 <bcos_> When only one logical CPU is in HLT, the core is not in C1 (it's being used by the other logical CPU) and when the "running" CPU causes a BP exception the running CPU handles the BP exception
10:44:29 * zid gets intimately familiar with the bochs debugger
10:44:35 <heat> oh, I think I know
10:44:35 <zid> for some reason one of my list heads is ending up -1 :/
10:44:47 <heat> it's because of hardware task switching
10:45:11 <heat> the wiki says it triggers a debug exception on task switch
10:45:41 <bcos_> Erm - what causes the hardware task switch?
10:46:52 <ohhithere> heat: can you elaborate?
10:47:13 <heat> no
10:47:23 <heat> I have no idea how hardware task switching works
10:47:32 <heat> I literally just read the wiki
10:48:40 <ohhithere> im talking about why would the cpu want to wake the logical core on unrelated debug exception?
10:48:54 <ohhithere> heat: can you refer me to the specific wiki page you're reading?
10:48:56 <bcos_> ohhithere: I think that there might be an external "force breakpoint" pin on the CPU (for freaky stuff nobody does) that triggers the breakpoint exception
10:49:02 <heat> I don't know and I also don't know why you would care
10:49:31 <heat> https://wiki.osdev.org/Exceptions#Debug
10:49:32 <bslsk05> ​wiki.osdev.org: Exceptions - OSDev Wiki
10:49:51 <bcos_> Also; don't confuse "debug exception" with "breakpoint exception". The breakpoint exception can only ever be caused by an int3 instruction (unless there's an external pin)
10:50:34 <ohhithere> bcos_: or hw bp, nope? (DRs)
10:51:08 <bcos_> D'oh - there is an external pin
10:53:40 <ohhithere> bcos_: you mean a physical cpu debug pin?
10:53:46 <bcos_> Yes
10:53:49 <gog> probably connects to a JTAG
10:54:19 <gog> or is there a hardware interface on x64 i don't know about
10:54:41 <gog> hardware debugging*
10:56:02 <ohhithere> nevertheless, an unrelated bp exception on different thread running on the same cpu wont wake the HLTed logical core?
10:56:06 <zid> Okay so it's actually a read from memory that doesn't exist, neato
10:56:52 <bcos_> ohhithere: It won't (but there's no "wake")
10:57:38 <ohhithere> bcos_: can you explain please?
10:58:50 <bcos_> For hyper-threading, imagine a CPU just has twice as many registers (including two EIP registers) and can feed two different instruction streams into the core's execution units. When one of the CPUs isn't running the other CPU just runs faster (gets full use of all execution units).
10:59:35 <bcos_> You can't turn all the executioni units off (e.g. put the core into a C1 state) just because one of the logical CPUs did a HLT
10:59:51 <bcos_> ..because that would prevent the "still running" CPU from running
11:00:22 <ohhithere> i see, but still, what intel meant in the manuals by saying that debug exception will wake the HLTed thread.
11:00:54 <ohhithere> did they mean only for non-HTT cpu?
11:01:24 <bcos_> If a CPU is HLTed and someone uses the external breakpoint pin (e.g. an in-circuit emulator), then that will cause a breakpoint exception that starts CPU running again
11:02:05 <ohhithere> i see, that clears things up, thanks :)
11:06:55 <ohhithere> just making sure i get it correctly, basically if a ring0 thread executed HLT, i should expect it to remain HLTed? or at what condition will it wake up? because there's no reason for the scheduler to wake it up, right?
11:14:19 <bcos_> ohhithere: Why did you HLT it?
11:14:57 <zid> Okay *someone* is lying to me about the RAM in this machine..
11:14:58 <bcos_> Normally you only ever HLT when there's nothing for CPU to do (no tasks for scheduler to run), which means that normally you want to stop HLT when a task becomes ready to run
11:15:33 <bcos_> zid: It was sortie - that's why he left IRC
11:15:43 <zid> Oh god I think I found it
11:15:57 <ohhithere> bcos_: theoretically speaking
11:16:22 <heat> i'm getting confused as to which threads we're talking about
11:16:38 <ohhithere> a logical thread on a HTT-enabled CPU
11:17:09 * bcos_ preferes "logical CPU" for that (but "hardware thread" is more common)
11:17:22 <ohhithere> oh, ok
11:17:30 <heat> okay, so, the thread will wake up when an external interrupt fires with the HLTed thread as a destination cpu
11:17:41 <zid> I realigned the first block to start at 2MB, but forgot to subtract the difference from the /length/ of the block. It immediately tries to allocate the final page - which doesn't exist
11:17:59 <zid> except it doesn't fail, it just reads back as 0xFFFFFFFF through ->next which corrupts my list head
11:18:04 <ohhithere> heat: that should happen?
11:18:15 <heat> ?
11:18:58 <heat> explain
11:18:59 <ohhithere> lets say, under windows, i loaded a driver, created a new system thread, and this thread executed HLT, theoretically speaking, will this thread get woken up?
11:19:05 <zid> woo it works now
11:19:15 <heat> a plain HLT with irqs enabled?
11:19:17 <heat> yes
11:19:47 <zid> bcos_: I implemented the list crap into my actual bootloader now, I just need to make it properly hand-off the struct it made and add a copy of phys_alloc to the real kernel
11:19:49 <ohhithere> heat: but why would "anyone" direct an exception/interrupt to this hw thread?
11:19:52 <zid> thanks for the design advice
11:19:55 <heat> eventually either a device irq or the scheduler timer will fire
11:20:01 <bcos_> zid: :-)
11:20:06 <heat> ^^
11:20:26 <heat> Either a device IRQ that sends interrupt to that CPU, or the timer IRQ that is per-thread
11:20:33 <heat> (hardware thread to be specific)
11:20:45 <bcos_> ..or an IPI from another CPU (e.g. multi-CPU TLB shootdown)
11:20:51 <zid> pew pew
11:20:53 <heat> yeah
11:20:59 <zid> (That is mandatory, someone has to say pew pew there)
11:21:06 <heat> EL TORITO
11:21:18 <heat> (that is also mandatory)
11:21:28 <ohhithere> heat: im talking about a hw thread, other hw threads are now hogging the cpu, and they will be the one/s to handle IRQs and get swapped by sched timers.
11:21:37 <ohhithere> this specific hw thread is halted
11:21:44 <heat> no
11:22:10 <heat> each hardware thread is a different CPU in a sense
11:22:15 <heat> the topology doesn't matter
11:22:31 <heat> all they share is an execution unit
11:22:51 <heat> they are seen as completely different cores with their own LAPIC, execution context, etc
11:23:20 <heat> if you have a plain 2-core 4-thread cpu, you have a CPU0, CPU1, CPU2, CPU3
11:23:37 <heat> lets assume CPU0 and CPU1 make core0, CPU2 and CPU3 make core1
11:23:45 <ohhithere> so to clarify my question, what i meant was, will the next instruction after the HLT instruction in the HLTed thread will ever be executed when the CPU is still alive and only this logical cpu entered C1?
11:24:02 <heat> if you send an external interrupt to CPU1, you will wake up CPU1 independently of it being hlted or not
11:24:42 <heat> I believe they have some kind of scheduler
11:25:37 <heat> since without it, you would lose the illusion of having more logical cores than physical cores
11:26:38 <heat> I would assume they try to share the CPU 50-50 and it only lets a hw thread hog the CPU when the other hw thread is halted
11:27:47 <bcos_> ohhithere: Assume it's like "core Cstate = max( logical_CPU1_fake_Cstate, logical_CPU2_fake_Cstate)" - impossible for one logical CPU to have the core in C1 while another logical CPU doesn't have the same core in C1
11:29:12 <heat> bcos_: I think they want to know how the core is shared between 2 hw threads
11:30:02 <bcos_> Hrm
11:31:49 <bcos_> Instead of having a core having a "while(running) { fetch(); decode(); execute(); }" loop; think of it as a "while( CPU1_running || CPU2_running) { (if(CPU1_running) fetch_CPU1(); if(CPU2_running) fetch_CPU2(); decode(); execute(); }"
11:34:27 <ohhithere> bcos_: in the second example there's a context switch occuring each iteration if both CPUs are active?
11:36:11 <bcos_> No
11:36:31 <Shockk> I have a quick POSIX question about file descriptor allocation
11:36:34 <Shockk> All functions that open one or more file descriptors shall, unless specified otherwise, atomically allocate the lowest numbered available (that is, not already open in the calling process) file descriptor at the time of each allocation."
11:37:07 <Shockk> does this mean that if a file is closed, then I should check if it's the new lowest numbered available?
11:37:29 <bcos_> ohhithere: Imagine you're throwing blue pebbles into a rock polisher and your friend is throwing red pebbles into the same rock polisher. When the polished rocks come out the other end you figure out whose pebble it is (is it red or blue?)
11:38:12 <bcos_> If you stop throwing pebbles in, nothing really changes - the rock polisher is still polishing rocks, but only blue rocks come out the end
11:38:16 <heat> Shockk: what do you mean with should?
11:38:34 <heat> should as in kernel or should as in user-space or should as in test suite?
11:39:00 <Shockk> I mean should as in if I want to be strictly compliant with that part of the spec
11:39:11 <Shockk> just wanting to know if I understand what it's saying
11:40:06 <ohhithere> bcos_: but does the cpu knows whether its currently executing instruction from which context? i mean, it should, otherwise to how does it know to which address space is being used? how does it line up with security?
11:40:23 <heat> Basically, POSIX imagines you have an array of fds and when you're allocating one you start from 0 until MAX_FD
11:40:46 <Shockk> right, that makes sense
11:41:14 <heat> after you close a fd, if it's the lowest numbered fd when you call open again you'll get that same fd
11:41:27 <Shockk> ahh right, that's what I was wanting to know
11:41:35 <Shockk> okay, that makes sense then
11:41:36 <Shockk> thanks
11:41:39 <heat> no problem
11:41:41 <zid> It's also super super fast, you don't need to piss around with hashmaps or linked lists or anything
11:41:49 <bcos_> ohhithere: The core is like a pipeline with multiple stages. The "front end" stages (fetch and maybe decode) generate micro-ops and tag them with a "logical CPU number", the middle part (execution units) don't care much which logical CPU micro-ops came from, and the back end ("retirement") figures out the "was it a red pebble or a blue pebble" part
11:42:19 <bcos_> (from the tags that front end added to the micro-op)
11:42:21 <Shockk> zid: right, I imagine I'll just remember the lowest fd, and when a file is closed, I can just check if it's lower than the lowest fd
11:42:27 <Shockk> (and if it is, update the lowest fd)
11:42:35 <heat> that's not a good idea
11:42:36 <zid> Shockk: It's even easier than that
11:42:44 <Shockk> oh
11:42:50 <zid> you just swap the pointers for it and the highest fd
11:42:55 <zid> so that there is never a 'hole' in the fdset
11:43:21 <heat> I check for the whole table of file descriptions
11:43:38 <heat> (which is an array of pointers)
11:43:40 <zid> so if you have given out 0,1,2,3 and someone gives you 2 back, you'd normally end up with a fragmented mess, but you can just do a single swap of 3 with 2 and all your 'holes' are at the end still
11:44:08 <Shockk> hmmm
11:44:13 <Shockk> oh I think that makes sense
11:44:15 <bcos_> zid: Is this for a managed language where you know all the places in memory/stack/heap that the FD might be stored,so you can update them all?
11:44:34 <zid> bcos_: no you just have to add a layer of indirection, this is for your internal filedes tracking
11:44:54 <zid> so FILE *f[MAX_FDS]; or whatever for converting fd into internal FILE *
11:44:55 <heat> how are you supposed to tell userspace you switched fds around?
11:45:04 <heat> Ah
11:45:15 <heat> So, that's not how C's FILE works
11:45:18 <Shockk> zid: and in that case, you just need to track *how many* open fds there are, right? so that when you go to open a new one, you don't have to iterate to find a hole, you just look at table[num open fds]
11:45:25 <zid> yea you just need to know how many there are
11:45:35 <Shockk> that's neat
11:45:46 <Shockk> errr but hmm
11:46:04 <heat> like theoretically FILEs can represent a lot of things, possibly even memory
11:46:06 <Shockk> you'd have to update the fd value inside the FILE* right?
11:46:37 <zid> Shockk: I'm like 90% sure you can get it working like this from this end anyway
11:47:00 <heat> Shockk: FILEs don't explicitly contain file descriptors
11:47:24 <zid> people do it the other way around in 99% of socket apps
11:47:28 <Shockk> oh huh
11:48:07 <Shockk> I mean, right now I have fread (which takes a FILE*) call read (which takes an fd)
11:48:12 <Shockk> and read does my syscall to the kernel
11:48:21 <Shockk> is it usually done the other way around?
11:48:32 <heat> no
11:48:42 <heat> it's done like that, but with callbacks
11:48:56 <heat> and fread and fwrite usually do their own caching
11:49:26 <zid> look at setvbuf and crap
11:49:27 <heat> so, for example, to support fmemopen you would have a FILE->read = file_memread and FILE->write = file_memwrite
11:49:30 <zid> stdio is supposed to be buffered
11:50:00 <Shockk> hmm right
11:50:01 <Shockk> I mean
11:50:02 <Shockk> hmm write