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=osdev2&y=21&m=11&d=22

Monday, 22 November 2021

01:18:00 <klange> Something I've done in my graphics stack, or something that changed in VBox, is annoying me... I seem to not get the initial message I used to get to switch the display mode... I think it might be from modesetting in my bootloader.
01:19:00 <klange> But it's annoying, because I start up in, like, 1024x768 because that's a suitable resolution VESA advertises and then... it just sits there.
01:19:00 <klange> Used to be I would have a pending message from the host-guest interface and it would snap to the right resolution from, like, a mouse interrupt.
01:20:00 <klange> I should update to the newer interface, I wrote this against the legacy one and it nags in the log every time.
02:50:00 <klys_> I've been asking about something in #qemu just it seems mebby nobody's there
02:50:00 <klys_> looks like this is the file I want modified: https://gitlab.com/qemu-project/qemu/-/blob/master/qemu-options.hx#L1281
02:50:00 <bslsk05> ​gitlab.com: qemu-options.hx · master · QEMU / QEMU · GitLab
02:50:00 <klys_> the modification would be to add physical and logical drive geometry options cyls, heads, secs, lcyls, lheads, lsecs.
03:00:00 <klys_> actually it may need to go here, https://github.com/qemu/qemu/blob/master/docs/qdev-device-use.txt#L67
03:00:00 <bslsk05> ​github.com: qemu/qdev-device-use.txt at master · qemu/qemu · GitHub
03:01:00 <klys_> and it looks like that's on gitlab too
05:39:00 <geist> klys_: yeah the qemu channel doesnt seem that busy does it
05:46:00 <moon-child> optimization I never knew I wanted: compiler should know to convert memmove(x, x + i, 64 - i) into memmove_asc_small(...)
05:48:00 <geist> i've been fighting addresses-of-fields-of-packed-structs
05:49:00 <geist> compiler really really dissuades you from doing that
06:01:00 <pounce> klys_: #qemu is on oftc, libera channel isn't very busy
06:28:00 <klys_> pounce, yeah I was doing oftc #qemu today
06:29:00 <pounce> oh sorry i haven't been in there long bouncer died
06:30:00 <klys_> my nick there is klysmo
08:18:00 <geist> i forget, whoever has dealt with pci before, is it incredibly important to read pci config registers in the right width?
08:18:00 <geist> i can imagine writing it almost certainly is
08:18:00 <zid> it says it is
08:19:00 <zid> whether the device controllers give a shit idk
08:19:00 <geist> yah i just replaced my routine that reads pci config space in a byte at a time with one that reads in all the fields in the correct width
08:19:00 <zid> I think you can combine on the 16s
08:19:00 <zid> err that is, two 8s
08:20:00 <geist> i'm guessing it's basically up to the device, but the spec says the device can be dumb and not handle sub field read/writes
08:20:00 <geist> and of course emulators probably generally speaking work fine with bytewise access
08:21:00 <zid> matching the size defo seems safest, and it's not performance or code density critical so whatever
08:21:00 <geist> oh totally
08:21:00 <geist> second question: i assume big endian machines have to deal with the implicit LE order? or... maybe they dont, because it's assumed you access fields with the correct width
08:22:00 <zid> hmm?
08:22:00 <zid> oh hmm
08:22:00 <zid> I guess if it's a 16bit 'char' for that field, there's no endian
08:22:00 <zid> but I don't think that's the case
08:22:00 <zid> I think it's byte addressable
08:22:00 <zid> and whether it allows combining up to 16/32/64/etc is up to the device
08:23:00 <geist> yah and if so then what's the endian order a pci config space?
08:23:00 <geist> i can imagine if the spec says 'the fields must be accessed in native sizes' then it can also appropriate swizzle based on the host cpu endianness
08:23:00 <zid> so if you read anything using wide reads it's going to be backwards on BE
08:23:00 <geist> since the pci bus controller presumably knows that
08:23:00 <zid> it's not swizzled
08:23:00 <geist> and if so that may be precisely why you're supposed to access them inthe native size
08:24:00 <zid> random quote from google cache of osdev, good job google
08:24:00 <zid> "PCI devices are inherently little-endian, meaning all multiple byte fields have the least significant values at the lower addresses. This requires a big-endian processor, such as a Power PC, to perform the proper byte-swapping of data read from or written to the PCI device, including any accesses to the Configuration Address Space. "
08:24:00 <geist> word.
08:24:00 <geist> intel definitely had their hand in it, so i guess at that point in time they pushed for LE
08:25:00 <zid> LE makes the most sense anyway, BE can die
08:26:00 <geist> i can't easily test it anyway since none of the BE arches i have ported to have a machine with PCI i can test on
08:26:00 <geist> unless i make a BE build of ARM or something
08:26:00 <geist> which, meh.
08:27:00 <zid> At any case, it's just 'ram' which.. becomes even more apparent when you use pci-e
08:27:00 <zid> where it's memory mapped but still identical
08:27:00 <zid> so you'll need to le_to_host it all if you do multi-byte reads
08:27:00 <geist> yah or you can consider it a big pile of MMIO registers that the device exports
08:28:00 <geist> i have seen some situations where the bus swizzles the data to the device based on the access width, since it knows the endian of the machine
08:29:00 <geist> i think there was some of that on playstation 3 for example, since the PPC/SPU cpus were big endian and the NV47 GPU was mostly little endian
08:29:00 <zid> I do all my reads as 32bit
08:29:00 <zid> then shift them around depending on the 'offset' I think
08:29:00 <geist> lots of swizzling in the textures and whatnot
08:31:00 <zid> addr = ENABLE | bus<<16 | device<<11 | func<<8 | (offset&0xFC); out(CONFIG_ADDR, addr); data = in(DATA_ADDRA); if(offset & 2) data >>= 16;
08:31:00 <zid> I don't remember *why* I do this though :D
08:32:00 <zid> oh because register offset must be xxxxxx00 maybe
08:32:00 <zid> so infact I had it backwards, and you *must* do 32bit reads?
08:36:00 <zid> The PCI pdf probably says all this, but I don't have one
08:36:00 <geist> hmm, for type 1 accesses, yeah i guess that's right?
08:36:00 <geist> ie, via the in/out access method?
08:37:00 <zid> yea, idk if you *can't* do that, for pci, it isn't memory mapped until pci-e
08:37:00 <geist> but writes, do you have to do a RMW if you want to just piddle with 8 bits? (I haven't iomplemented that for type 1 accesses)
08:38:00 <zid> I imagine so? There address selection is agnostic to reads or writes
08:38:00 <zid> s/There/the
08:38:00 <zid> You're still doing out32(CONFIG_ADDR, ...); regardless of reading or writing
08:38:00 <zid> and that's the part that masks the bottom 2 bits as 0
08:39:00 <zid> so you can only select dword aligned addresses, so a rmw might be needed (or you just keep a local copy and keep it in sync, but you're not an idiot so idk why I typed this bit)
08:39:00 <zid> I don't have code for it, the only writes I do are 32bit for the BARs
08:39:00 <geist> oh i dunno, i mean i could look this up
08:39:00 <geist> but it seems like a nice topic
08:40:00 <zid> oh the command reg is 16 I do touch that.. I wonder what's next to it..
08:40:00 <zid> ah, status
08:40:00 <zid> I imagine writing to those doesn't matter
08:40:00 <geist> but yeah looks like the type 1 config accessor is definitely 32bits at a time, in aligned 32bits so
08:41:00 <zid> 32bit write to BAR, 32bit write to status | command
08:41:00 <geist> yah possibly they carefully arranged it such that bits you write to are always shared with bytes that dont latch on write
08:41:00 <geist> cleeeever
08:41:00 <zid> The other one you might wanna mess with is the bridge control | int pin | int line one
08:41:00 <geist> or a bunch of 8 bit fields you want to write all at once
08:42:00 <geist> ah also notice the capabilities pointer is not shared with anything
08:42:00 <zid> so just treat that as one big field I guess
08:42:00 <zid> bridge_pin_line
08:42:00 <geist> though i guess yo never write to that
08:45:00 <geist> so i gues that begs the question: with pci-e are you always supposed to read the ECAM in 32bit offsets
08:45:00 <geist> or more importantly: write to it in units of 32bits
08:46:00 <geist> probably no, but it does beg the question as to what happens if you have a PCI device on a PCI-to-PCIE bridge and you access its config in 8 bit intervals
08:46:00 <zid> I think pci-e is flexibable because the bus acts like memory and they have to support 'the pci-e bus'
08:46:00 <geist> and it was previously never accessable that way
08:46:00 <zid> hmm yea that's a good one
08:46:00 <zid> I wonder if the bridge has to split/combing
08:46:00 <geist> right
08:50:00 <zid> orr the pci-e bridge just has to be treated like a bridge, and you have to use its interface to issue pci writes, and it's specified the same way as pci was
08:53:00 <zid> like, there's just an mmio reg on the pci-e device that is the bridge, which implements 0xCF8 and 0xCFC or whatever, and says 'do it like pci'
08:55:00 <zid> found a random TI pci-e to pci bridge chip's doc, it just says "this device acts like a pci to pci bridge type 1"
08:57:00 <zid> And I think the spec for that says there's a register that's 0 if 16bit io is supported, 1 if 32bit
08:58:00 <zid> yea header type 0x1, pci-to-pci bridge, pci reg 0xC (offset 0x30)
09:01:00 <geist> nice
09:43:00 <klange> I just want to say that the Shell Command Language specification in POSIX is by far the worst language specification it has ever been displeasure to place in front of my eye balls.
09:46:00 <zid> geist: made in abyss s2 (3rd part, with the movie) has preview visuals being released :o it's coomiiing
09:46:00 <geist> oooh
09:47:00 <geist> klange: is that basically a spec for sh?
09:48:00 <kazinsal> seems to be yeah
09:48:00 <kazinsal> quite thorough
09:48:00 <kazinsal> https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html
09:48:00 <bslsk05> ​pubs.opengroup.org: Shell Command Language
09:49:00 <klange> it is _the_ spec for sh, and it is an astounding feat of non-linear storytelling
09:50:00 <moon-child> I just saw
09:50:00 <moon-child> somebody implementing the visitor pattern. In _C_
09:50:00 <zid> I don't even know what that is, my soul is untarnished
09:51:00 <moon-child> zid: I envy you
09:52:00 <zid> The wikipedia example is like "A naive way would be *perfectly reasonable way to do it*"
09:52:00 <zid> as though functions can't exist
09:53:00 <klange> I do know what that is, but I do not feel unnerved.
09:53:00 <kazinsal> one of those enterprise programming paradigms where everything is a ClassInitiatorProviderFactoryFactory
09:54:00 <zid> yea it definitely looks like "We don't understand how to write code in the first place, so this is one of the hacks we came up with"
09:54:00 <moon-child> I mean, it kinda makes sense given you're already using java. In c I have no idea why you would want it
09:54:00 <zid> Moving operations into visitor classes is beneficial when
09:54:00 <zid> many unrelated operations on an object structure are required,
09:55:00 <zid> Also known as "functions accepting pointers"
09:55:00 <zid> "new operations need to be added frequently" also known as "functions accepting pointers"
09:55:00 <zid> etc
09:56:00 <klange> Ignore the class aspect for a moment; is the visitor pattern not evident in functions like qsort? It is about implementing algorithms in ways which may accept various objects, and about implementing the type-specific functionality without extending the particular types.
09:57:00 <kazinsal> it makes sense when your productivity is purely judged by lines of code
09:57:00 <moon-child> I don't think using function pointers constitutes visitor pattern. It's the weird inversion of control and the large amounts of boilerplate
09:57:00 <zid> qsort being well known to be absolutely awful
09:57:00 <kazinsal> when you need 50 lines of boilerplate per each actual operation line...
09:57:00 <zid> "A drawback to this pattern, however, is that it makes extensions to the class hierarchy more difficult, as new classes typically require a new visit method to be added to each visitor. "
09:58:00 <zid> It'd be like if you had to add a qsort comparitor function for every single type, by the sounds of it
09:58:00 <zid> as soon as you started using qsort anywhere in your code
09:59:00 <klange> No, just for anything that would be sortable.
09:59:00 <zid> which is anything, potentially
09:59:00 <klange> The alternative to the visitor pattern is to have common class functions - eg. interfaces.
09:59:00 <moon-child> klange: qsort isn't ISortable, it's parametric polymorphism. It's just that they both look like void* in c
10:00:00 <kazinsal> dog bless the language that forces us all to double-check our every move
10:00:00 <zid> If my pointers ever look like `void* ` you can shoot me btw
10:01:00 <moon-child> qsort :: [a] -> (a -> int) -> [a]
10:01:00 <kazinsal> if I need something resembling polymorphism in C I use anonymous member structs with plan9-extensions
10:01:00 <zid> okay I found an easy code example for it, it looks *exactly* like adding a common interface to a set of objects
10:01:00 <klange> tagged unions
10:01:00 <zid> but with a stupid name
10:02:00 <zid> and an extra function to call all of them
10:02:00 <klange> zid: The visitor pattern is, rather literally, implementing a common interface separately from the classes.
10:03:00 <kazinsal> eg. all of my interface types start with an anonymous net_generic_t; so you can send a specific interface to any function that takes a net_generic_t and also so any change to net_generic_t automatically propagates to each interface struct
10:03:00 <klange> For example, say you want to write a JSON serializer. You _could_ add an interface, an "IJSONSerializeable" or whatever, and implement the method across all the classes you want to serialize...
10:03:00 <zid> I don't know what any of that means ^
10:09:00 <klange> The visitor pattern is for hot-patching an interface onto things that didn't implement it.
10:11:00 <zid> I mean, that just sounds.. completely normal?
10:12:00 <zid> If I want to know about how many otters my 'class' (read: .c file) has captured, I add a function to tell me
10:15:00 <moon-child> zid: open-world assumption
10:16:00 <zid> pardun
11:27:00 <stultusv> bochs loops between f000:e05b and f000:fff0, never reaches 0x7c00... What might cause this?
12:55:00 <j`ey> if I have .text : AT(0xXXXXXX), should I see my text section at XXXXX when I objdump?
12:55:00 <j`ey> or does objdump default to address 0
12:57:00 <gog> AT() only sets the physical address hint i think
12:57:00 <gog> objdump cares about the virtual address afaik
12:58:00 <j`ey> ah
12:59:00 <zid> lma, rather than phys
13:00:00 <zid> .section VMA : AT(LMA) { . == VMA } >append_to_VMA AT>append_to_lma
20:30:00 <kingoffrance> re: visitor pattern wikipedia emphasizes double dispatch. https://en.wikipedia.org/wiki/Double_dispatch there is a silly ruby example there. all that is just to say: i think if you had <thing to do, e.g. qsort()> <comparison function> one more layer of indirection on top of qsort, that would be closer
20:30:00 <bslsk05> ​en.wikipedia.org: Double dispatch - Wikipedia
20:31:00 <kingoffrance> not advocating either way, just seems one level above qsort if one was to make that comparison (no pun)
20:41:00 <kingoffrance> or, alternately, qsort invoked with a chain of comparison functions (to break ties, something beyond single level, single comparison function). I believe that would also be closer
22:34:00 <immibis> Mutabah: yes. see also: how to make artificial general intelligence (1) recognize MNIST digits (2) make the rest of the (fucking) intelligence
22:34:00 * Mutabah is away (Sleep)
22:34:00 <immibis> i'm pretty sure the instructions have to contain the word "fucking"
22:34:00 <immibis> how to write any program: (1) write hello world (2) write the rest of the (fucking) program
22:35:00 <immibis> i think in osdev the (1) is an GDT and IDT
22:47:00 <geist> haha
22:48:00 <rustyy> TIL about queued spinlocks, i feel pretty good =)
22:48:00 <kazinsal> if your OS doesn't spontaneously crash after 24 hours of uptime, you can move onto the "write the rest of the fucking operating system" stage
22:54:00 <klange> 24 hours is easy; the real benchmark is when you've forgotten a VM running on another workspace for three weeks and you find the clock still ticking.
23:12:00 <kazinsal> and it's still switching packets like a champ
23:14:00 <geist> rustyy: ooooh
23:14:00 <geist> do tell!
23:23:00 <kingoffrance> thats almost Schrödinger ...if a server is buried in a wall and people forgot it exists, is it still routing packets? have to open it up and see
23:28:00 <geist> so easy with wifi too. you can easily forget you had some raspberry pi on the network somewhere
23:28:00 <geist> or one that's embedded in some other thing
23:43:00 * gog embeds a rasbperry pi into herself
23:43:00 <gog> am borg
23:43:00 * gog assimilates the channel
23:49:00 <vdamewood> We are dyslexic of Borg. Prepare to have your ass laminated.