Search logs:

channel logs for 2004 - 2010 are archived at ·· 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

Thursday, 9 March 2023

00:00:00 <brunothedev> gonna steal it from bare bones hehehehe
00:00:00 <mrvn> And to be correct you need one that specifies memory regions but nearly everyone ignores that and prays it won't break.
00:00:00 <mrvn> (which it does if you leave the 2MB default page size in the linker invokation)
00:01:00 <FireFly> klange: I enjoy the parallel intercal dialect that adds parallelism by letting multiple comefroms reference the same location
00:08:00 <mrvn> Maybe I should look into how to propose an addition to C/C++, intoducing named or numbered loops so you can break/continue and outer loop.
00:15:00 <brunothedev> offtopic, but how to add recursive dependencies in make
00:15:00 <heat> what do you mean
00:16:00 <brunothedev> nevermind, found a fix
00:16:00 <heat> ok
01:22:00 <brunothedev> gnu assembler when inputed with the -c option, just outputs a a.out file, how to change this to the c compiler defualt: [filename].o, i need this for a makefile
01:22:00 <Mutabah> `-o` - this should be in the `--help` output
01:24:00 <heat> you should use gcc to assemble anyway
01:28:00 <brunothedev> heat: oh ol
01:28:00 <brunothedev> Mutabah: i have a variable called SDEPS who include ALL assembly files, quite hard to -o that
01:29:00 <heat> i don't know what you're doing but it sounds like you're makefile is severely borked
01:29:00 <heat> s/you're/your/
01:35:00 <Mutabah> Agreed
01:36:00 <Mutabah> You should be using a makefile with pattern rules for each file type
01:36:00 <Mutabah> so you can easily send the output somewhere sensible
01:46:00 <brunothedev> how to include makefile variables on the $(shell ...) call? OFFTOPIC
01:49:00 <brunothedev> writing a makefile is getting painful
01:49:00 <brunothedev> should i try meson
01:49:00 <brunothedev> ?
01:51:00 <Mutabah> ... wait, why are you using `$(shell)`?
01:52:00 <Mutabah> Also, you can just stick a `$(VARNAME)` inside the call
01:52:00 <brunothedev> Mutabah: fine ./ -name '*'.c
01:52:00 <brunothedev> * find
01:52:00 <heat> can't wait to find out he's invoking as using shell
01:52:00 <Mutabah> Bad idea
01:52:00 <Mutabah> don't just glob all input files - expliclitly list the
01:52:00 <Mutabah> *list them
01:53:00 <heat> thats also not the GNU make way of doing a wildcard
01:53:00 <Mutabah> (In fact: I list them using the object file form, because that's how they're going to be used)
01:53:00 <heat> same
01:53:00 <brunothedev> i have not found a way to make a if to lists files as per archtecture
01:54:00 <brunothedev> like: if $(ARCH) == i686 then ... end
01:54:00 <brunothedev> heat: > "can't wait to find out he's invoking as using shell" not THAT dumb
01:54:00 <Mutabah> `ifeq ($(ARCH),ii686)` `OBJS += file_for_i686.o` `endif`
01:55:00 <klange> I use 'include' for that: `include ${ARCH}.mk` and then ${ARCH}.mk has all the arch-specific stuff.
01:55:00 <Mutabah> All of this should be well covered in make's documentation
01:55:00 <Mutabah> klange: Nice idea
01:56:00 <brunothedev> klange: cool idea
01:57:00 <klange> There's also a $(wildcard kernel/arch/${ARCH}/*.c) somewhere in the main makefile; the ${ARCH}.mk files mostly define how to run qemu for tests.
01:58:00 <klange> I also do a bunch of other stuff, like ${ARCH} is populated based on a gitignore-d file so you set it once and then `make` does what you want in the future, similar to an autoconf-prepared build.
01:59:00 <klange> I also have a thing that makes loadable modules only build for a given arch if they have "@package ${ARCH}" in them somewhere. I'm big on the automatic discovery and resolution stuff.
02:08:00 <brunothedev> offtopic: My kernel makefile includes the main makefile to load variables, but the main makefile loads the kernel makefile, how to load variables of the main makefile without it calling again
02:10:00 <klange> you're doing something backwards in one direction or the other
02:10:00 <heat> offtopic: [OFFTOPIC] **TOPIC IS OFF** (NO TOPIC) sup
02:10:00 <klange> if you're doing recursive make, your top-level make file should never include its children - it should cd into their directories and recursively run make
02:13:00 <brunothedev> klange: my top level do not include make, the children does include to load some user variables like ARCH and TOOLCHAIN
02:13:00 <heat> export
02:14:00 <brunothedev> heat: ** ABSOLUTELLY NO TOPIC ** (TOPIC IS DEAD) [TOPIC'S BLOODLINE IS ERASED] lul
02:14:00 <klange> I suggest having just one makefile. recursive make was a mistake
02:15:00 <klange> (or one makefile that includes others for specific configs, like the setup I described)
02:16:00 <brunothedev> klange: yes, you are probaply right, i just took it because linux does this
02:16:00 <brunothedev> also, compiling a whole os with one make doesnt seems right
02:16:00 <klange> lies
02:17:00 <Mutabah> Look at what linux does, and do the opposite :)
02:17:00 <klange> I used to literally build my whole OS with one makefile, but technically it's a few dozen generated ones included in a top-level one now.
02:18:00 <heat> i don't do any of this because make sucks ass
02:18:00 <klange> the only thing that sucks ass about make is how it handles spaces
02:18:00 <heat> scourge of build systems
02:19:00 <heat> no.
02:19:00 <heat> for one, include is insane, just a copy paste
02:19:00 <klange> yes, hello, i write c
02:19:00 <heat> you need a shit ton of macros just to make a large GNU makefile remotely usable and simple
02:20:00 <heat> at that point... why?
02:20:00 <klange> I _have_ considered turning my whole build process into a Kuroko script. It's already mostly one, anyway - the real fun is all in the tool that builds the makefiles for the userspace apps.
02:20:00 <heat> klange, meson is written in python
02:20:00 <heat> just sayin :))
02:24:00 <klange> really need to get around to writing a gzip compressor, the one last thing my own native build tools lack...
05:33:00 <chibill> Question if I setup the APIC (enable it) should I be getting any new interrupts right away? Or do I have to configure the APIC Timer first?
05:37:00 <geist> well, you dont have to do anything really, but the apic timer is probably the first one you'll want to fiddle with
05:38:00 <geist> also there's a local and ioapic, they're both sometimes called apic
05:38:00 <geist> but i assume you're tlaking about the local apic
05:51:00 <chibill> Yea the local APIC. Trying to figure out how to get something that is simular to the timer interrupt you get automatically with PIC. (Since I am using UEFI I can't use the older PIC interface)
05:52:00 <geist> sure. well the local apic timer is pretty simple once you get it set up
05:52:00 <geist> and it just fires directly on whatever vector you set it. usually set it to something high, like 250. though really doesn't matter
05:53:00 <geist> and of course the reason you use it as the timer is because on an SMP machine you almost always want a timer per cpu
05:53:00 <geist> so need one 'local' to each cpu
05:53:00 <chibill> I did read that you have to somehow use other intrrupt to actual figure out how quickly the APIC timer fires or something. Is the PIT still useable even if the PIC isn't?
05:54:00 <geist> well. okay there is that problem
05:54:00 <geist> there's a pile of ways to compute the local apic timer speed. one of the advantages of PIT is it runs at a known speed
05:54:00 <geist> you can even use the PIT to calibrate the local apic timer
05:55:00 <Ermine> so PIT is not PITA?
06:02:00 <geist> mmmm, pita
06:02:00 <geist> with some hummus
06:30:00 <Ermine> I guess someone is hungry
11:43:00 <brunothedev> how to get grub-file?
11:51:00 <immibis> what is grub-file?
11:51:00 <immibis> klange: I rather suspect most people would port gzip; creating an OS doesn't mean you have to reinvent all the data-pushing code that has nothing to do with OSes
11:52:00 <zid> sounds fun to write regular ass zip by hand though
11:52:00 <zid> idk about anything newer
11:53:00 <brunothedev> immibis: see it on the multiboot wiki page
11:54:00 <immibis> oh a tool which checks file type
11:55:00 <immibis> zid: zip is actually more of an OS/filesystem thing than a compression thing; you outsource the compression to deflate
11:55:00 <immibis> I have grub-file on my computer; seems to be installed as part of grub
11:56:00 <brunothedev> immibis: what distro
11:56:00 <immibis> gentoo
11:56:00 <brunothedev> using fedora here
11:57:00 <zid> immibis: come over here and say that
11:57:00 <immibis> brunothedev: check if they called it grub2-file instead
11:57:00 <brunothedev> immibis: already did this
11:58:00 <brunothedev> lmao i found it
11:59:00 <brunothedev> now i just need to build grub
11:59:00 <immibis> brunothedev: it's included in grub2-tools RPM.
11:59:00 <bslsk05> ​ grub2-tools-1:2.06-88.fc39.aarch64.rpm | RPM Info | koji
11:59:00 <brunothedev> and make an iso
12:00:00 <immibis> (well, you are probably using x86_64, not aarch64, but it should have the same stuff)
12:01:00 <brunothedev> immibis: wdym
12:01:00 <immibis> i just clicked on the aarch64 package because it was first in the list
12:02:00 <immibis> CPU architecture for fedora. I was looking at fedora packages to see which one had grub-file and I clicked on aarch64 first
12:02:00 <brunothedev> u also clicked on the testing release package
12:03:00 <immibis> that just proves how I'm not using fedora
12:03:00 <immibis> it gets the point across. they don't change this stuff across architectures or releases
12:03:00 <immibis> well, they can change it across releases, but they usually don't
12:17:00 <brunothedev> so, shold i set on grub.cfg gfxpayload=keep
12:22:00 <nortti> if your grub boots into graphical mode, yes
12:24:00 <brunothedev> unsupported tag: 0x68
12:40:00 <brunothedev> idoes anyone know what is the 0x68 tag?
12:44:00 <FireFly> what kind of tag?
12:45:00 <brunothedev> FireFly: see the error above, the multiboot2 command of grub is giving me that
12:48:00 <klange> brunothedev: you either didn't put an end tag, or you have an alignment error
12:49:00 <klange> alignment errors are a pretty common mistake with a first attempt at doing multiboot2
12:50:00 <brunothedev> klange: my linker script is like the bare bones one but insteand of 4 align it is 8
12:51:00 <klange> not going to be in your linker script, gonna be in the assembly where you build the request tags
12:51:00 <brunothedev> klange: there is align 8 at my assembly header too
12:51:00 <klange> "a" is probably not enough
12:51:00 <klange> you need each tag to be aligned
12:52:00 <brunothedev> klange: i used and modified your multiboot2 header
12:53:00 <klange> you'll need to link some code if you want any help
12:56:00 <brunothedev> klange: just wait
12:56:00 <klange> i'm waitin'
12:57:00 <brunothedev> klange: brunix.tar.xz:
12:57:00 <bslsk05> ​redirect ->
13:04:00 <klange> brunothedev: your address tag is malformed
13:05:00 <brunothedev> wdym?
13:06:00 <sham1> It's malformed. As in it doesn't work
13:07:00 <brunothedev> sham1: but why
13:07:00 <klange>
13:07:00 <bslsk05> ​ Multiboot2 Specification version 2.0
13:07:00 <klange> The address tag is 24 bytes long. Yours its 12. You are missing three longs.
13:09:00 <gog> long long long
13:09:00 <klange> You also don't need this tag at all if you are building a 32-bit ELF. I have one because I occasionally build more exotic things.
13:10:00 <brunothedev> just gonna delete it, since ia m using arch/i686
13:12:00 <gog> uefi uefi uefi uefi uefi
13:12:00 <brunothedev> ong it worked
13:12:00 <brunothedev> just throwed a black screen but it is a good start
13:13:00 <Ermine> gog: may I uefi you
13:13:00 <Ermine> hi btw
13:13:00 <gog> hi
13:13:00 <gog> yes
13:13:00 * Ermine uefis gog
13:14:00 <gog> EFI_GOG_PROTOCOL
13:14:00 <brunothedev> lemme re-bios you
13:14:00 * brunothedev re-bios'ed gog
13:15:00 <gog> sorry i had my bios removed
13:15:00 <Ermine> secure gog boot declined bios?
13:16:00 <gog> bios replacement therapy
13:16:00 <brunothedev> now i need ato atleast draw ONE pixel, i can bootstrap a console latter, just how to draw a pixel
13:19:00 <Ermine> very weird part message
13:19:00 <brunothedev> Ermine: i love part messages
13:19:00 <gog> you just draw a pixal
13:20:00 <brunothedev> gog: how
13:20:00 <gog> idk i've never drawn pixal before
13:20:00 <gog> get its (x, y) into an offset ig
13:20:00 <gog> then add that offset to the base of the framebuffer
13:20:00 <gog> then write the pixel
13:21:00 <brunothedev> gog: it is just easy as this
13:21:00 <gog> it is because i was lying i have drwan pixal before
13:21:00 <GeDaMo> base + (row * no_of_columns) + column
13:22:00 <gog> not quite
13:22:00 <gog> row * pitch
13:22:00 <gog> pitch might be greater than width
13:22:00 <GeDaMo> Fair enough :P
13:23:00 <brunothedev> i have the framebuffer address too
13:23:00 <gog> do you know the other properties of the framebuffer
13:23:00 <gog> pitch and pixel format
13:23:00 <gog> and width and height
13:24:00 <gog> if you don't then you can't really do anything with it
13:24:00 <nortti> < GeDaMo> base + (row * no_of_columns) + column < gog> row * pitch ← isn't it base + ((row * pitch) + column) * bytes_per_pixel?
13:24:00 <brunothedev> i have the address, pithch, width and height, and bpp
13:24:00 <gog> yes
13:24:00 <brunothedev> i could list more here
13:24:00 <gog> great
13:24:00 <gog> that's all you need really
13:24:00 <gog> but do you know the pixel format
13:25:00 <brunothedev> color?
13:25:00 <gog> yeah
13:25:00 <gog> bgr or rgb
13:25:00 <gog> bits per field
13:26:00 <brunothedev> apparentlly there is a way to discover, but no
13:26:00 <brunothedev> gog: here it is the example code:
13:26:00 <bslsk05> ​cloudblaze/multiboot2 - multiboot2规范的示例代码 (0 forks/1 stargazers/GPL-3.0)
13:27:00 <gog> do you understand the code or are you just blindly copypasting it
13:27:00 <brunothedev> gog: i understand what i have written
13:28:00 <gog> ok
13:28:00 <brunothedev> do i do not understand what "distance" meand
13:29:00 <brunothedev> * tho i do not understand what "distance" means
13:29:00 <gog> that's for framebuffers with a configurable palette
13:29:00 <gog> so a pixel value represents an index into that palette
13:29:00 <zid> I have a configurable palette, so i have decided today I shall eat nothing but cake
13:30:00 <gog> keep on trying until you run out of cake
13:32:00 <brunothedev> i think this is how to draw: "multiboot_uint32_t *pixel = fb + tagfb->common.framebuffer_pitch * i + 4 * i;"
13:35:00 <brunothedev> i think the bpp is forced to 32 by klange
13:35:00 <klange> None of that framebuffer header forces anything, it is just asking nicely
13:35:00 <gog> if the underlying device can't do it then it won't
13:35:00 <gog> it'll do the next best
13:35:00 <brunothedev> gonna do this:
13:36:00 <klange> it is quite late here, so I am disconnecting from my pseudo-bouncer
13:36:00 <brunothedev> if (tagfb->framebuffer-bpp != 32)
13:36:00 <klange> good night
13:36:00 <brunothedev> while(1) {}
13:37:00 <brunothedev> here in brazil it is 10:36
13:37:00 <brunothedev> timezones are weird
13:38:00 <nortti> you may with to use hlt in your hang-loop, so that it doesn't end up burning CPU power for nothing
13:39:00 <brunothedev> nortti: sooooo: "__asm__ __volatile__("hlt")" /
13:39:00 <brunothedev> ?
13:40:00 <nortti> yeah, I think so. (I usually don't use inline asm)
13:44:00 <gog> nini klange
13:46:00 <brunothedev> what is the best way to separate the video driver from the main kernel?
13:47:00 <brunothedev> like, a driver folder where you ask the user if it wants to include the driver
13:47:00 <brunothedev> on the makefile
13:48:00 <brunothedev> also, my code is doing nothing
13:48:00 <nortti> it's probably fair to build every driver unconditinoally until your kernel gets to like, tens of minutes of compiling
13:50:00 <brunothedev> nortti: ok, bt how to split the two?
13:52:00 <brunothedev> WHAT DO I DO WITH *PIXEL !!!!!!!!!!!!
13:52:00 <gog> you write a value to it
13:53:00 <brunothedev> gog: already did this, what do i do wih it now
13:53:00 <gog> the pixel should appear in your display
13:53:00 <nortti> < brunothedev> nortti: ok, bt how to split the two? ← I'd have kernel/video/fb.c that gets compiled to fb.o and then linked into your final kernel binary
13:53:00 <gog> if it doesn't then you did something wrong
13:54:00 <brunothedev> uint32_t *pixel = fb + tagfb->framebuffer_pitch * i + 4 * i;
13:54:00 <gog> yeah
13:54:00 <gog> then *pixel = <pixel value>;
13:54:00 <brunothedev> wait, maybe it is hitting a hlt
13:55:00 <gog> what you have is the address of the pixel
13:55:00 <brunothedev> gog: what do i do with it?
13:55:00 * gog blinks
13:55:00 <gog> you... write a value to it
13:56:00 <gog> unt32_t *pixel = ... is getting a pointer to the pixel in its framebuffer
13:56:00 <gog> *pixel dereferences the pointer
13:56:00 <gog> = is assignment to the memory at that address
13:56:00 <brunothedev> maybe i should write a color struct to it
13:56:00 <gog> yeah probably
13:57:00 <gog> forgive me if this is an off-base question but how much do you know about programming in general? like what's your background?
13:58:00 <brunothedev> gog:
13:58:00 <bslsk05> ​ Bruno Henrique Silva Aguiar · GitLab
13:58:00 <bslsk05> ​ brunothedev (Bruno Henrique) · GitHub
14:01:00 <gog> ok
14:01:00 <gog> so you don't have a lot of experience with low-level programming in C
14:02:00 <gog> but you can learn
14:03:00 <brunothedev> gotta prepare to school
14:03:00 <brunothedev> goodbye
14:03:00 <Matt|home> to be fair i only recently learned something..
14:04:00 <Matt|home> i was curious how you'd write a driver for something like an arduino.. apparently you can just directly write to memory locations using the IDE. i assume it's a fair bit more complex doing something like that with a phone over usb for example?
14:04:00 <Matt|home> if you could do that at all that is, i assume it's mostly write protected
14:07:00 <gog> yeah µc's tend to have GPIO memory-mapped
14:07:00 <gog> so you just blat bytes at it
14:13:00 <zid> I mean, so do real cpus
14:14:00 <zid> memory mapped is both old-hat and super modern :P
14:14:00 <zid> we just had a weird piece in the middle where we were using i/o instructions
14:15:00 <nikolar> got to love 8/16 bit x86
14:18:00 <gog> yes
14:19:00 <gog> i don't even know why x86 has that separate i/o bus?
14:19:00 <gog> is it because the address bus was so limited?
14:19:00 <zid> possibly yea, plus it's simpler for low speed cheap isa devices
14:19:00 <zid> to not have to run at memory bus speeds
14:19:00 <gog> makes sense
14:21:00 <nortti> I think x86 specifically has them because 8080 had them, and there you only got 16 bits of address bus total
14:21:00 <nortti> original IBM PC runs ISA at same speed as memory, I'm pretty sure
14:21:00 <zid> 1MHz?
14:22:00 <zid> that's some nice fast memory
14:22:00 <nortti> oh did it ran memory at lower speed than the CPU?
14:23:00 <nortti> oh huh yeah, "memory operations happened at 1/4 this frequency, at 1.19 MHz -- crystal / 12." as per
14:23:00 <bslsk05> ​ ibm pc - How much did IBM save by limiting the PC to 4.77 MHz? - Retrocomputing Stack Exchange
14:29:00 <heat> linux operating system kernel
14:29:00 <heat> guyz what iz ur favorite linux
14:29:00 <heat> i like freebsd
14:29:00 <nortti> my favourite linux is ELKS
14:30:00 <nortti> one of the very few systems that can claim to be a "different kind of linux" fully literally
14:31:00 <gog> is haikuOS a linux
14:31:00 <gog> if so its the best one
14:31:00 <heat> "Linux kernel developers Alan Cox and Chad Page"
14:31:00 <heat> fake names?
14:31:00 <gog> Chad and Cox
14:32:00 <gog> checks out
14:32:00 <gog> chex
14:32:00 <zid> heat: Chad Linux
14:40:00 <heat> chadOS
14:40:00 <zid> I upgrading from shitpc todayyy
14:40:00 <zid> back to realpc
14:40:00 <Ermine> virginOS where
14:41:00 <zid> Ermine: linux
14:41:00 <Ermine> Hehe
14:41:00 <Ermine> zid: also complexpc where
14:42:00 <heat> hehehehehehehe
14:45:00 <zid> soviet PC biggest PC n the world!
14:45:00 <zid> fitted with forklift handles for easy carrying!
14:46:00 <heat> counterfeit soviet vax >>
14:46:00 <Ermine> I've seen one actually
15:23:00 <heat> TIL in C++ void foo(int arg...); = void foo(int arg, ...);
15:23:00 <Ermine> o_O
15:24:00 <heat> it does make sense honestly
15:24:00 <gog> soyuz nerushmii
15:24:00 <heat> i agree
15:27:00 <zid> isn't that you can do A, B style macro expansion where A may not be present
15:27:00 <zid> and not have the extra comma explode you
15:27:00 <zid> I thought C11/23 also had it, but may have been a fever dream
15:28:00 <mrvn> Isn't the first an implicit vardiac template and the second VA_ARGS?
15:35:00 <heat> zid, no that's something else
15:36:00 <heat> that's GNU C specific stuff (__VA_ARGS__ "hiding" the last , when used like VAR_MACRO(10, __VA_ARGS__))
15:36:00 <heat> OR C++20 specific stuff __VA_OPT__(,) expands to , if __VA_ARGS__ isnt empty
15:37:00 <heat> I'm really unsure if C23 has this, maybe it does
15:37:00 <heat> this is literally just a case of varargs in C++ not requiring a comma
15:39:00 <heat> "Where syntactically correct and where “...” is not part of an abstract-declarator, “, ...” is synonymous with “...”."
15:44:00 <mrvn> Isn't a context free grammar beautiful?
15:48:00 <mrvn> Is there ever a reason to use VA_ARGS in C++ outside of extern "C"?
16:07:00 <heat> yes, sane codegen that doesn't blow up your binary
16:13:00 <zid> okay time to do some osdev
16:13:00 <zid>
16:19:00 <heat> mjg, hello!!!
16:20:00 <heat> is an atomic OR a bad lock operation?
16:20:00 <heat> with this I mean like a fetch_or
16:21:00 <heat> fwiw it does seem to compile down to a cmpxchg
16:22:00 <heat> (because there's no fetch_or op in x86)
16:23:00 <mjg> it is a massive crapper but if you have to do it...
16:23:00 <mjg> in general cmpxchg *loops* are shit, but not always avoidable
16:24:00 <mjg> see the lockref debacle
16:24:00 <heat> the idea here is to have a page flag also serve as a lock, like linukz
16:25:00 <mjg> welp also see fribzd
16:26:00 <heat> like won't my spinlocks have a cmpxchg loop? or at least an xchg one
16:26:00 <heat> what should I search for? symbol name
16:26:00 <mjg> looping to set something in the var vs to take a lock are very different senarios
16:27:00 <heat> yeah but in this cae something in the var *is* the lock
16:27:00 <mjg> e.g. vm_page_dequeue
16:29:00 <heat> what's a queue here?
16:29:00 <mjg> does it matter?
16:29:00 <heat> yes?
16:29:00 <mjg> see vm_page.h
16:30:00 <heat> i just want a lock_page/unlock_page primitive
16:30:00 <mjg> it's just a bunch of shitters -- is the page in use, is not in use
16:30:00 <mjg> etc.
16:30:00 <mjg> well page "lock" in freebsd is a massive crappe,r see vm_page_sbusy
16:30:00 <mjg> erm vm_page_trysbusy and similar
16:30:00 <heat> why is everything a crapper to you :(
16:31:00 <heat> do you keep shitting yourself
16:31:00 <mjg> not *everything*
16:31:00 <mjg> i think sequence counters are a great invention
16:32:00 <heat> this code is very hard to read
16:32:00 <heat> everything is one 's' away from bussy greatness
16:33:00 <heat> ok so it's also a cmpxchg loop
16:33:00 <heat> great
16:34:00 <mjg> like i said
16:35:00 <mjg> vm likes to boast about being "commented very well"
16:36:00 <heat> better commented than linux for sure
16:37:00 <mjg> was gonna say the comments don't really help
16:37:00 <mjg> what savesthe bacon to some extent is asserts all over the place
16:37:00 <mjg> to document the insane requirements
16:38:00 <heat> are you sure you like freebsd
16:39:00 <heat> have you ever praised any of it, ever?
16:39:00 <mjg> i literally just did
16:39:00 <mjg> > asserts
16:39:00 <heat> > insane requirements
16:39:00 <mjg> how did that slip in there
16:39:00 <mjg> really though, if you are fucking around, freebsd is morel ikely to tell you that you messed up thatn ilnux
16:40:00 <mjg> there is an ingrained culture on asserting the shit out of everything
16:40:00 <mjg> this slowly changes in linux though
16:40:00 <mjg> normally freebsd will have lul_lock_assert_held(&fooobj);
16:40:00 <mjg> while linux will have acomment: /* yo dawg make sure you hold the lock, but i'm not gonnacheck if you do even on a debug kernel */
16:40:00 <Ermine> lul
16:40:00 <mjg> again that last bit is changing
16:41:00 <mjg> i asked an Important Developer once what's up with the comments
16:41:00 <mjg> instead of asserts
16:42:00 <heat> what did linus tell you
16:42:00 <mjg> and he was liek "what's the problem. the comment tells you what to do"
16:42:00 <mjg> not that guy
16:42:00 <heat> matthew garrett for sure
16:42:00 <mjg> i'm gonna protect the guilty on thiso ne
16:42:00 <Ermine> or greg kh?
16:42:00 <heat> actually I know who it is
16:42:00 <mjg> i guarantee you don't
16:42:00 <heat> must be Ingo Molnar
16:42:00 <heat> on god
16:43:00 <mjg> so linux got an annotation to funcs that it expects or rleases a specific lock
16:43:00 <mjg> also the machinery to detect violations, when actually used, is more informative
16:44:00 <heat> why the fuck does vm_page_bits_t change sizes based on page size?
16:46:00 <mjg> it indicates invlalid rangs
16:46:00 <mjg> invalid ranges
16:47:00 <heat> wat the fuck is wrong with these comments
16:48:00 <mjg> thek eyboard on you man
16:48:00 <mjg> take a chill pill
16:48:00 <mjg> #notmedicaladvice
16:48:00 <heat> The following annotations are possible: (A), (B), (C), (F), (M), (O), (Q)
16:48:00 <mjg> what. commented on.
16:48:00 <heat> 250 uint8_t flags; /* page PG_* flags (P) */
16:48:00 <mjg> job done boss
16:48:00 <heat> I SEEMED TO HAVE MISSED P
16:48:00 <mjg> job done boss
16:48:00 <mjg> comments are essintial to deliver high quality
16:49:00 <heat> take some opioids
16:49:00 <heat> #medicaladvice
17:28:00 <heat> mjg, is there no benefit in adaptive-spinning instead of sleeping for the page lock?
17:28:00 <mjg> there is massive benefit
17:28:00 <mjg> adaptive spinning is almost always a win
17:28:00 <mjg> in fact waiting on the page lock is one of the biggest bottlenecks
17:29:00 <mjg> you may ask why not done then -- because nobody implemented it
17:29:00 <heat> lol
17:29:00 <mjg> you may notice a tech difficulty here: the entier field is only 4 bytes
17:29:00 <mjg> so a full thread addr wont fit
17:30:00 <mjg> not a huge problem to solve, but there are some competing choices to be made here
17:30:00 <heat> but erm
17:30:00 <heat> so, you say adaptive spinning is almost always a win
17:30:00 <heat> why?
17:30:00 <mjg> however, more important news, is that most of the problem is because there is too much xbusy when it could be sbusy after some effort
17:30:00 <mjg> because going off cpu is costly af
17:30:00 <mjg> and induces even more cost for the thread doing the unlock later
17:31:00 <mjg> and if the lock is heavily contested, performance collapses to nothing if everyone just goes off cpu
17:31:00 <mjg> ... because the idled cpu time which is "gained" is spent on adding more threads to wake up
17:31:00 <mjg> it just works out this way in practice
17:32:00 <mjg> i can't stress the word *adaptive* enough -- it has to *react* to owner going off cpu
17:32:00 <heat> sure but I would think it would suck as an anti-other-threads-in-the-same-CPU measure?
17:32:00 <mjg> as i said previously in practice you *lose* time by going off cpu
17:32:00 <mjg> by the time you context swithc away the lock is very likely free
17:33:00 <heat> ok so this is a stats thing? behaves well for some locks but not for others?
17:33:00 <mjg> except now you added work for the previus owner
17:33:00 <mjg> i already told yu there is one dgenerate case wher it sucks: when locks are taken in lockstep, so tto speak
17:33:00 <mjg> apart from that it is expected to be a win
17:34:00 <mjg> at worst it happens to not be implemented in some cases
17:34:00 <mjg> see above for one
17:35:00 <heat> does this apply to every software system out there?
17:35:00 <heat> could you expect big wins from adaptive spinning in userspace (if you had the previously-discussed oncpu flag stuff)
17:35:00 <mjg> yes
17:36:00 <mjg> i stress the diff between this and just "spin some time deemed long enough and gtfo"
17:36:00 <mjg> also note people handroll spinlocks in hopes of never going off cpu
17:36:00 <mjg> i userspace
17:36:00 <heat> yes but that's mad mkay
17:36:00 <heat> *bad. but mad also works
17:37:00 <mjg> so for example "parking_lot" crate for rust gets a win over stock rust
17:37:00 <mjg> because they spin
17:37:00 <mjg> arbitrary amount of time, but they spin, instead of blindly going off cpu at the first wiff of contention
17:38:00 <mjg> one thing you may note it shaves a syscall trip, even if ultimatley you do't go off cpu
17:38:00 <mjg> should you get the lock while in the kernel, without going off, now you got extended lock hold time becausey ou have to get back
17:38:00 <mjg> it all goes to shit really fast
17:39:00 <mjg> extended hld time means someone else is more likely to find the lock taken and rinse & repeat
17:39:00 <mjg> fwiw perf goes to shit if i disable adaptive spinning in the ernel
17:40:00 <mjg> simiarly, linukkz got a win after *adding* adaptive spinning to their rwsem
17:40:00 <mjg> laso you may notice they spinlock by default anyway
17:42:00 <heat> yeah
17:44:00 <heat> locking is herd
17:44:00 <mjg> no, just realities suck
17:44:00 <mjg> for user code
17:46:00 <mjg> if you want an example abuser which piles on a poor sap lock, it would be make
17:46:00 <mjg> -j 104 spawns *hundreds* of makes, majority of which keep doing poll() on *the same* pipe
17:46:00 <mjg> and doing r/w on it as well
17:47:00 <mjg> it is bad to the point where lock waiters take long enough, that once they get the lock they happen to get preempted
17:47:00 <mjg> then everyone else has to add themselves to thet urnstile and wake the owner up
17:48:00 <heat> something something spinlock?
17:48:00 <mjg> in fact, with some other patches added, 'pipe lock' is the most contested out there by a large margin
17:48:00 <mjg> 749236678 (sleep mutex:pipe mutex)
17:48:00 <mjg> 73674398 (rw:vmobject)
17:48:00 <mjg> wait times
17:48:00 <heat> so spinlock.
17:48:00 <mjg> that would amage-control the problem to some extent
17:48:00 <mjg> but wont fix it
17:49:00 <mjg> there is a real fix tho
17:49:00 <mjg>
17:49:00 <bslsk05> ​ bmake: Replace token pipe with shared memory. · macdice/freebsd@cfeb5b4 · GitHub
17:49:00 <heat> does a pipe write do broadcast wakeup?
17:49:00 <heat> probably?
17:49:00 <mjg> i don't remember, but that's not where bulk of the cntention is
17:50:00 <mjg> almost all of it is in pipe_poll
17:50:00 <mjg> note it gets queried whether there is a good reason or not
17:50:00 <mjg> as in the main poll loop waits for a bunch of crap and wakes up a lot regardless of what happens to the shared pipe
17:50:00 <mjg> and when it goes back to poll() it lands in pipe_poll again
17:51:00 <mjg> things get drastically better if this gets replaced with kqueue
17:51:00 <mjg> but they still stuck
17:54:00 <mjg> ooh and when it wakes up from poll it does it *again* :p
17:54:00 <mjg> contention on that sucker is massively amplified
21:30:00 <brunothedev> gog: are you here?
21:57:00 <netbsduser> i've just had a eureka moment: the secret to paging the page tables themselves is that for each entry in a table pointing to a lower-level table, you have to consider one pin to exist on the higher-level table. a non-terminal table can be in the swapfile, only if each entry in it is null or the swap address of a lower-level table
21:58:00 <geist> i suppos eyeah. OTOH, swapping page tables is a really bad idea
21:58:00 <heat> i agree with geist, bad idea
21:58:00 <geist> but yeh i think keeping the constraint as you say makes a lot of sense
21:59:00 <heat> do note that you could just outright remove the page tables if you didn't store the swap data in the PTEs
21:59:00 <heat> what stores the page structs can also store the swap data :)
22:00:00 <brunothedev> netbsduser: do you realy use netbsd?
22:00:00 <heat> no, it's the one system he doesn't use
22:00:00 <heat> SVR4 lover, solaris lover, freebsd lover, openbsd mega lover, netbsd hater
22:00:00 <netbsduser> without the constraint you end up in a hell of having to page-in one table so you can update its PTE for the paged-out inferior table to point into swap
22:01:00 <netbsduser> heat: i was keeping the swap address in a separate structure before but i am unhappy with the memory use
22:01:00 <heat> why?
22:02:00 <heat> lets imagine you have a union {u64 swap_data; vm_page_t *page;} vmobj_entry;
22:02:00 <heat> how is this not superior?
22:03:00 <netbsduser> i have that but i also have a lock in there which enlarges it to some 40 bytes
22:03:00 <heat> why a lock?
22:04:00 <netbsduser> my vm_page_t contains a pointer the object that it belongs to and for anonymous memory, since anonymous pages are shareable, the object must be considered the individual anonymous page vmobj_entry
22:05:00 <netbsduser> (for a file mapping it points to the actual vnode memory object and the vm_page_t has linkage for a tree to chain it into the object, since file objects aren't subject to 'symmetric cow' like anonymous memory is)
22:06:00 <brunothedev> from someone who likes openbsd, freebsd is the worst one lol
22:07:00 <netbsduser> i like freebsd's capsicum
22:07:00 <heat> oh boy
22:07:00 <heat> someone hold me
22:10:00 <heat> would rather use 1996 SunOS over 2023 openbsd
22:11:00 <CompanionCube> wasn't it Solaris by 1996?
22:11:00 <brunothedev> heat: openbsd looks neat from linuc
22:11:00 <brunothedev> * linux
22:11:00 <netbsduser> sunos already had coherent mmap() and read()/write() in 1996 (well, no later than SVR4 actually) which is one point in its favour there
22:11:00 <heat> CompanionCube, it was
22:12:00 <CompanionCube> yep, Solaris 2.5.1, released May 1996.
22:12:00 <heat> my bad, would rather use 1994 SunOS
22:12:00 <brunothedev> openbsd is very portable and very lightweight
22:12:00 <brunothedev> looks cool
22:12:00 <heat> haha
22:12:00 <netbsduser> >very portable
22:12:00 <brunothedev> heat: someone runned one on a imac g3
22:12:00 <heat> netbsduser, yes they had coherent mmap+rw() through the worst method ever of getting this same coherency
22:12:00 <CompanionCube> had Motif, NFSv3, pthreads, doors
22:12:00 <netbsduser> doesn't even have a vax port smh
22:13:00 <CompanionCube> heat: STREAAAAAMS
22:13:00 <netbsduser> heat: i think it's a cute approach
22:13:00 <nortti> brunothedev: you should look at netbsd if you like a currently developed bsd with high portability
22:13:00 <netbsduser> but i have a bit of an obsession with weird approaches to virtual memory
22:14:00 <heat> netbsduser, you basically throw away any advantage you could have from read()/write()
22:14:00 <brunothedev> nortti: didnt someone run netbsd ON A TOASTER
22:14:00 <heat> for, what, virtual memory in the kernel? fucking hell
22:14:00 <brunothedev> i dont like bloat, so netbsd and openbsd looks cool
22:14:00 <heat> ok i'll bite
22:14:00 <heat> what's so bad about freebsd and linux
22:14:00 <nortti> brunothedev: probably, but like, that's honestly not very interesting? it'd've been a toaster with some commodity chip designed to be able to run a whole OS
22:14:00 <brunothedev> if it wasnt by nvidia, i would run alpine with swaywm
22:15:00 <netbsduser> heat: i suppose you could just walk the vnode's memory object manually too
22:15:00 <heat> netbsduser, yes, something you'll do eventually, but directly
22:15:00 <heat> and with further idea of what you're actually there to do (how much should you prefetch, etc)
22:17:00 <heat> nortti, btw really enjoyed the dig at openbsd, welcome to the club
22:17:00 <heat> sortie would NOT enjoy this
22:17:00 <nortti> haha
22:18:00 <nortti> wasn't even meant as a dig tbh, openbsd just genuinely has less ports than netbsd
22:18:00 <heat> yeah but "current developed bsd" really hit the spot there
22:19:00 <nortti> heh
22:19:00 <nortti> oh, interesting, netbsd doesn't have a luna88k port (openbsd does)
22:20:00 <heat> oh man not the luna88k
22:20:00 <nortti> tho from what I understand it's like, one dev keeping that going, and they probably have their hands full enough with openbsd already
22:20:00 <nortti> netbsd does do luna68k tho
22:20:00 <brunothedev> openbsd is more secure
22:20:00 <heat> mjg
22:20:00 <brunothedev> it does means that it haves by default fewer drivers
22:21:00 <nortti> brunothedev: you might like
22:21:00 <bslsk05> ​ Is OpenBSD secure?
22:21:00 <heat>
22:21:00 <heat> nortti, fuck
22:21:00 <heat> ur 2fast
22:22:00 <heat> oh wow it only got syn cookies in 2018
22:22:00 <nortti> < brunothedev> it does means that it haves by default fewer drivers ← not even necessarily, aiui it had the latest (or was it the one gen before?) wifi drivers before other BSDs. might be there is something I don't know, but from what I understand lack of drivers is mainly about lack of developers to work on them
22:22:00 <nortti> *latest gen
22:23:00 <heat> aren't all the wifi drivers taken from linux?
22:23:00 <netbsduser> openbsd is called the queen of open source wifi drivers
22:23:00 <heat> this is a legitimate question
22:23:00 <netbsduser> linux once snatched one of their wifi drivers and tried to strip out the BSD licence which caused a shitstorm
22:23:00 <nortti> huh
22:24:00 <heat> yes but erm, when was that
22:24:00 <netbsduser> 2008 i think
22:24:00 <heat> I seriously doubt any corp is contributing code to openbsd in 2023
22:24:00 <heat> particularly wifi drivers
22:24:00 <netbsduser> oh, they cook them up by themselves
22:24:00 <heat> "how much documentation do you want?" "all of it" "too bad, here's none"
22:24:00 <netbsduser> this was when everyone left the penguin out to dry
22:25:00 <heat> ok so it was the queen of open source wifi drivers 25 years ago
22:25:00 <heat> sorry, 15 years ago
22:28:00 <heat> hahaha
22:28:00 <bslsk05> ​ pinsyscall | Is OpenBSD secure?
22:35:00 <brunothedev> klangis bpp the same as pixelwidth
22:35:00 <heat> yes
22:41:00 <heat> [84722.098529] Out of memory: Killed process 80888 (shellcheck) total-vm:1073758092kB, anon-rss:4842880kB, file-rss:384kB, shmem-rss:0kB, UID:1000 pgtables:13512kB oom_score_adj:200
22:41:00 <heat> cheers
22:48:00 * kof123 switches to openbsd "I seriously doubt any corp is contributing code to openbsd in 2023"
22:53:00 <brunothedev> kof123: virgin coorporate controlled linx vs. chad independant free openbsd
22:53:00 <AmyMalik> greh
22:53:00 <AmyMalik> Linux has faster wifi
22:53:00 <brunothedev> i dont use wifi anyway
22:53:00 <AmyMalik> probably faster ethernet too
23:08:00 <brunothedev> what is: "framebuffer_[red/green/blue]_field_position" "framebuffer_[red/green/blue]_mask_size"
23:26:00 <immibis> probably the position and size of the red, green and blue fields
23:28:00 <brunothedev> immibis: so to draw, i need to draw at three different buffers for each color?
23:28:00 <immibis> what does your question mean?
23:29:00 <brunothedev> is there three different buffers, and i need to draw to each one for each color?
23:29:00 <immibis> no, there's one buffer with intermixed red, green and blue
23:30:00 <brunothedev> but is the buffer split between colors?
23:30:00 <immibis> these fields are probably telling you which part of each pixel is red, green and blue
23:30:00 <klange> do you know what BGR is?
23:31:00 <immibis> so you have an array of pixels, each pixel has red, green and blue, but sometimes it's like 5 bits red, 6 bits green, 5 bits blue; other times it's 8 bits unused, 8 bits red, 8 bits green, 8 bits blue
23:31:00 <immibis> sometimes it's blue, green, red. It's a shame the specification doesn't actually say what they mean exactly
23:31:00 <brunothedev> klange: blue green red?
23:37:00 <immibis> of course if you are just playing around you could hardcode whichever framebuffer format is used on your computer with your bootloader
23:37:00 <immibis> if that's easier