IRC channel logs
2026-08-09.log
back to list of logs
<damo22>int err = smbc_getFunctionStat(ctx) (ctx, np->nn->abs_file_name, &st); this is returning -1 <nexussfan>Nice, looks like Mesa3D (the version from sourceforge) works on hurd. Plib, SDL, GLX also work with it too. <damo22>youpi: please ignore smbfs patches i have v2 coming that I have tested and works <azert>damo22: regarding the discussion we had last year on usb ugen driver. I think the part missing was the creation of the device nodes <azert>that said, ugen ioctls are not compatible with the Hurd because they use structs with pointers <azert>as such, pooka’s ugenhc wouldn’t just work on the Hurd <damo22>its difficult to merge things upstream for rump because the framework is looking for a new maintainer <damo22>and the makefiles need refactoring <damo22>azert: im not sure if you are correct, the whole point of ugen is to split the usb stack in two. If it requires a pointer to memory in a different process, how can that work at all? <azert>damo22: ugenhc was meant to be used with the netbsd kernel as a host <azert>there it work because the host controller can just copyin and copyout data <azert>the rumpkernel makes a syscall , a ioctl, providing the pointer to the buffer <azert>it is a bad design of course <azert>to emulate that would take lots of wasted effort, same as the drmkms api <azert>reality is that it is deep in the unix philosophy to believe that processes run in kernel space and as such can copyin/out as much as they want <azert>the gnu/hurd is breaking a dogma here <azert>the usb host wouldn’t even need to be root in the Hurd, eventually