IRC channel logs

<damo22>youpi: the ioctl interface of drm is kind of neater than rpcs with lots of parameters, is there any way to make mig work with nested structs?

<attosphere>i find the DRM ioctls to be pretty strange, to do something simple like query the available video modes

<attosphere>you have to get a count of connectors, crtcs, encoders, then allocate memory for them, then call ioctl agaaain

<damo22>attosphere: even if its a dumb interface, it would be better to not have to reimplement an api for it because i have to write the client as well

<damo22>what id like to do is expose a compatible server interface so libdrm can mostly just work

<attosphere>and then there's the issue of aquire/release signal

<attosphere>which causes black screen issues

<damo22>attosphere: i plan to support only grub framebuffer to start

<attosphere>actually the signal issue might not exist if there is no VT subsystem at all

<attosphere>nvm

<damo22>what is the sizeof (void *)

<damo22>does it depend on 32/64 bit?

<attosphere>also as a side note, on linux you can't mmap a drm dumb buffer unless you're using 64bit file offsets

<damo22>-D_FILE_OFFSET_BITS=64

<damo22>and use off_t

<attosphere>the drm pointer type? yeah it's arch dependent but the kernel uses __u64 iirc

<damo22>ok

<attosphere>kernel-side structs, rather

<damo22>i might use off_t

<damo22>which is always 64 bit for hurd

<attosphere>another issue is that afaict (could be wrong), you might also need the sysfs interface

<attosphere>for setting backlight/birghtness

<damo22>heh

<damo22>skip that for now

<attosphere>and uevents for detecting hotplugging

<attosphere>it's really not well designed at all IMO, they just threw patches on patches

<attosphere>like the uevents won't tell you what was hotplugged, just that "something happened" then you have to scan sysfs

<damo22>lol

<damo22>so my problem is, the version ioctl has the pointers to strings and their lengths in the wrong order

<damo22>i dont think mig knows how to put the length before the buffer

<attosphere>they must really hate pascal strings if true

<attosphere>this convo is good motivation to get me to try compiling mach/mig/hurd again, i know too little about all this

<attosphere>oh fun got some compiler errors to battle

<attosphere>gnumach-1.8+git20240406/ipc/ipc_kmsg.h line 167 _Static_assert is missing , "some message"

<damo22>how do i implement an OUT ioctl that copies some strings to the client?

<damo22>i cant pack it into a struct

<damo22>because mig gets confused

<damo22>the only difference i can see between normal RPCs and ioctls is that the ioctl packs the entire set of params into a struct

<attosphere>second one is i386/i386/pcb.c:729, missing scope blocks around declaration in case stmt

<attosphere>and a bunch of multiple definitions of libc functions (do i have to build a HURD specific toolchain ??)

<attosphere>libgcc-routines.o -- anyway i'll stop making all this noise i need sleep BBLB

<lakeblue>when i enable the hurd console, random characters occupy all of the screen and i can not see anything. i tried console -d vga and console -d ncursesw

<lakeblue>i am running under qemu x86_64

<lakeblue>anybody has ideas? i couldn't find anything on the web

<lakeblue>i want to enable hurd console as apparently mach console only supports the US layout

<hakanrw>i tried qemu -vga std and virtio options

<hakanrw>its the same

<crupest>I guess I should change an email client. I really don't know why Thunderbird adds an invisible space at the beginning of body.

<gnucode>broskies I am sooo sorry! I completely forgot the Hurd halloween party that I invited everyone to! My bad!

<gnucode>I owe ya'll like $500,000. Who wants it?

<user_oreloznog>hi gnucode! Very nice https://gnucode.me/services.html but 'joshua@dismail.de' apparently doesn't work...

<gnucode>user_oreloznog: thanks! Yeah...the dismail.de email address is using my unfinished opensmptd service

<gnucode> https://gnucode.me/submitting-opensmtpd-service-to-guixrus.html

<gnucode>which is unfinished....

<user_oreloznog>Ah ok :)

<gnucode>it was meant as encouragement for me to finish and submit the service definition...

<gnucode>sneek later tell almuhs Sorry I forgot about the halloween party. I forgot and also slept in. My fault. :(

<sneek>Will do.

<user_oreloznog>gnucode: Yeah, it sounds promising... Congrats!

<gnucode>thanks. You're welcome to help me finish it. :)

<user_oreloznog>gnucode: I'm not a coder, just an end user and it will be a pleasure to help as I can.

<janneke>which gcc are you using? i'm trying gcc-14 and its strictness prevents me from building grep-.11

<janneke>possibly a gcc-13 is new enough and less troublesome?

<janneke>(that's for x86_64)

<janneke>re grep: sigsegv.c:844:3: error: #error "You need to define two of SIGSEGV_FAULT_ADDRESS, SIGSEGV_FAULT_STACKPOINTER, HAVE_STACKVMA, before you can define HAVE_STACK_OVERFLOW_RECOVERY."

<gnucode>user_oreloznog: well, at the moment my guix system has some pretty bad filesystem corruption on /gnu/store

<gnucode>so apparently I need to do a guix gc --verify

<gnucode>once that is fixed, I'll reach out.

<user_oreloznog>gnucode: no worry, it's cool.

IRC channel logs

2024-11-03.log