IRC channel logs

<damo22>ok the queue.h implementation points the ->next at head of the list instead of NULL

<damo22>that is where my code exploded

<damo22>or head->prev points to itself and the tail->next points to itself

<azert>I think antrik on the mailing list misunderstood what libdrm is

<azert>It’s not a thin abstraction supporting multiple backends

<azert>and the ioctl api is official, it is not an internal detail

<azert>also he seems to ignore that the api uses userspace pointers as handles

<azert>finally, how can a framework for high performance kernel drivers be portable?

<azert>of course it is not portable at all and all the bsd people are struggling to keep pace with that

<azert>for the Hurd running Wayland on the console/grub frame buffer and enabling mesa software rendering would be more than sufficient

<azert>but I suspect that mesa software rendering has been completely broken by the Linux drivers programmers

<youpi>the mesa stack has been compiling fine over the years, except some PATH_MAX issues and non-drm build fixups popping here and there

<youpi>I haven't worked on it recently so it's not building, but it shouldn't be hard to fixup

<saravia`>Hi, question the thinkpad T60 require coreboot? for run a gnu/hurd distro?

<damo22>ah crap, the problem is addresses of each callout structure is not unique because they are statically allocated

<damo22>so reusing them breaks the structure

<damo22>but i cannot kalloc inside an interrupt

<damo22>what do i do? create a linked list of fixed size and chew elements from that?

<saravia>excuse me for use T60, coreboot is require in hurd?

<nikolar>coreboot isn't required for hurd

<saravia>thank you

<saravia>ACTION return in less

<azert>damo22: I think that most of these interrupts could just use a single timeout element and change it on the fly

<azert>using the equivalent of the FreeBSD callout_reset

<azert>in some cases this might need a special allocator and a pool of objects, like you mentioned

<damo22>i dont understand how it works because as soon as you are working from a copy of the timer object, the original no longer has the state

<damo22>so how do you do things like stop the timer?

<damo22>you need a valid expiry on the original timer to look up the copy

<azert>damo22: can you point to the problematic call to set_timeout where you cannot kalloc?

<damo22>kalloc isnt the problem

<damo22>i can splx() and then kalloc

<damo22>the problem is having a copy

<azert>like when?

<damo22>09:46:30 AM) damo22: i dont understand how it works because as soon as you are working from a copy of the timer object, the original no longer has the state

<damo22>so theres no handle to look up the copy

<azert>I cannot follow you

<damo22>when you dont use a copy, you can use t->t_time

<damo22>ie the expiry on the original object tells you which wheel spoke its in

<damo22>if you make a copy of the timer, the original timer can only store t_time once

<damo22>so its only valid for one of them in the wheel

<damo22>and you dont know which one it corresponds to

<damo22>so how can you make a copy and stop that timer?

<azert>why do you need to make a copy?

<damo22>i think you need to make a copy because the same timer is reused again and again in the wheel?

IRC channel logs

2025-12-04.log