IRC channel logs

<damo22>azert: the point is, you cant replicate the linux drm ioctl interface exactly in hurd because some of the pointers being passed are virtual addresses that wont be able to be dereferenced by the client

<damo22>so if you pass the pointer, it will be useless

<azert>damo22: you can use and interpret those pointers in the ioctl hooks that you can install in glibc , do you agree with that?

<azert>those live in the same address space as the clients

<azert>You cannot implement drm, you can emulate it

<ZhaoM>anatoly: thanks for the suggestion, I forgot diff can be used to check the difference between two binary files :P

<damo22>azert: i dont follow, i thought if a hurd server mallocs a chunk of memory and passes a pointer to it via RPC to a client, the client cannot dereference it, it needs its own copy or mapped pages

<damo22>but the drm api is based around passing pointers to virtual addresses directly

<azert>damo22: absolutely.

<damo22>so we cannot implment the exact same api, it wont work

<damo22>i mean we could implement passing of the pointers but the pointers wont be referencable

<azert>No. Did you look at the _HURD_HANDLE_IOCTL mechanism?

<damo22>not yet

<azert>youpi pointed us to it

<azert>It lets you hook the ioctl in glibc, check it!

<damo22>i imagine that will allow us to define the ioctl as a more complex beast

<azert>Yes

<damo22>but it wont solve passing of pointers that need to be accessible

<azert>Part of it can live in the same address space where the pointer is deferenciable

<azert>It solves it up to a certain point

<damo22>but we dont really want drm living in glibc

<azert>We do

<azert>glibc is the right place to emulate linux

<azert>You don’t want the gpu drivers in glibc of course

<azert>I’m afraid those need to be Hurd specific

<damo22>so it will allow us to define an ioctl the same as linux api but then we can choose to map the address as a memory object and pass that through an rpc?

<azert>Yes, for instance

<damo22>that will be complex

<azert>Maybe most of it you can just implement it as hooks without any rpc

<damo22>well, the intention was to implement all the rpcs as stubs so we can fill them with real gpu drivers one day

<azert>I know, but you hit a wall

<damo22>probably starting from the middle of the stack is a bad idea

<azert>You can implement all the ioctl as stub instead

<azert>Using the _HURD_HANDLE_IOCTL mevhanismy

<azert>What do you mean?

<damo22>you cant have a display without KMS

<azert>Yes

<damo22>drm uses kms

<damo22>so probably we need to implment kms first

<azert>That’s a good idea, but aren’t those the same thing more or less?

<damo22>no

<damo22>kms is a different standalone subsystem

<damo22>drm is a thin layer around high level functions with buffers on gpus

<azert>I read it as KMS is a component of DRM

<damo22>kms modesets the display and configures all the connectors/encoders/crtcs

<damo22>it is very complex

<azert>It’s way too complicated

<azert>Why do we even need all of this?

<damo22>to initialise the display framebuffer you need this

<damo22>the hardware doesnt have an ON register

<damo22>you have to poke registers everywhere to configure it

<azert>Honestly, I am almost sure that the hardware is more simple than that

<damo22>no man

<damo22>look at libgfxinit for coreboot i915

<damo22>its very complex

<azert>What part of the gpu makes it so complex? Is it the programmable pipeline part or the fixed function display controller?

<damo22>all of it

<damo22>it has to negotiate with the monitor to find the best mode

<damo22>and then configure all the connectors etc

<damo22>all in software

<damo22>DVI, DP, analog, HDMI etc etc

<azert>Thing is, you don’t really want to implement this

<azert>If coreboot does it for you, you can just take it as it is

<damo22>yes, but coreboot only does intel gfx

<damo22>and if you want acceleration you need to reinit the card anyway

<azert>What about efi?

<azert>Doesn’t efi also initializes the card?

<damo22>to populate all the structs that drm needs

<azert>I’m think that the Hurd should keep it simpler

<azert>You can perhaps just implement a drm emulation layer

<azert>That looks like drm to mesa, but in fact it doesn’t do almost anything

<damo22>yes if you only want grub/efi framebuffer support

<damo22>we could implement a dumbfb driver for drm

<damo22>that inherits a const struct kms

<azert>I think you want that

<damo22>that is what i had planned

<azert>Simply because anything else requires an enormous effort

<damo22>but i want it to be extensible so one day someone else could add the real gpu support

<azert>Do you mean using the Linux drivers?

<damo22>yes

<damo22>if our kms implmentation is struct compatible with linux kms then the support could be added easily

<azert>Then, are you sure that they work with virtual client addresses? Can you point me an example where this happens?

<damo22>(07:06:34 PM) damo22: +S_drm_get_sarea_ctx (

<damo22>(07:06:34 PM) damo22: + drm_t drm,

<damo22>(07:06:34 PM) damo22: + uint32_t ctx_id, uint64_t *handle)

<damo22>this expects the server to do *handle = value; and pass the handle back to the client?

<damo22>i dont think that will work in hurd

<damo22>unless it only wants one u64

<azert>No it won’t work

<azert>There is another plan that can work

<damo22>hmm i cant find the linux implementation for that

<azert>You implement the dumbfb driver as part of glibc.

<azert> https://www.tuhs.org/cgi-bin/utree.pl?file=FreeBSD-5.3/sys/dev/drm/drm_context.h This is bsd

<azert>So, the plan would be that you implement just the dumbdb, and then whoever wants to

<azert>imolement an nvisia

<azert>Video driver for the Hurd, does all the hard work to implement it from svratcg

<azert>Of course , when the Hurd will be a popular kernel

<youpi>damo22: > but it wont solve passing of pointers that need to be accessible

<youpi>Yes it will: inside glibc you can just allocate data

<damo22>ok

<damo22>do i special case the 'd' ioctl?

<damo22>for drm

<damo22>in glibc

<damo22>why is glibc salsa maintained as a separate debian/ folder and an external src tarball

<damo22>all the other packages seem to be in tree

<damo22>it makes development a bit more difficult because the source is not in git

<sneek>wb solid_black!

<solid_black>sneek: botsnack

<sneek>:)

<sneek>Yey! solid_black is back!!

<janneke>should the latest 64bit image boot?

<janneke>with 20240825 i'm getting: ext2fs: part:1:device:wd0: Input/output error

<janneke>okay, it works fine with qemu-7.2.4

<janneke>guix default, 8.2.2 is problematic (on which -M q35 does not work at all)

<janneke>the Input/output error also shows when using qemu-7.2.4 without -M q35

<janneke>youpi: it looks like gnumach's 1.8+git20240714 tag hasn't been pushed

<janneke>i'm "guessing" (by looking at salsa/debian) it would be at a40012115277aeff07ff92abab652b996be3c9cf

<janneke>the 64bit binaries built by guix don't run

<janneke>task22(pid711)->task_get_special_port (4) = 0 36<--33(pid711)

<janneke>Child 711 Killed

<janneke>so i'm inclined to try using the exact gnumach version that 20240825 uses (that one works)?

<youpi>indeed, now pushed

<janneke>thanks!

<janneke>20240825 dpkg -l says: glibc 2.39-8, but debian salsa only has 2.39-7

<janneke>i'm wondering if i need

<janneke>Implement setcontext/getcontext/makecontext/swapcontext for Hurd x86_64

<youpi>janneke: -8 was not uploaded, but you have it in salsa, just before the 2.40 merge, 094703b40bb7d86be83472275ae89ffb33c8d846

<youpi>janneke: set/get/make/swap context is not strictly needed, but various packages will want it

<janneke>youpi: thanks!

<janneke>youpi: the 1.8+git20231217 tag for mig is also missing

<janneke>i'd better upgrade mig too

<janneke>if that's the version that was used in 20240825

<youpi>indeed, pushed

<janneke>thanks

IRC channel logs

2024-11-09.log