IRC channel logs

<damo22>youpi: how do i test the udeb changes i made?

<damo22>is there a script to build the installer image?

<mghackerlady>Is there any work being done on USB support? If so, is there a development roadmap of sorts?

<sneek>Welcome back mghackerlady, you have 1 message!

<sneek>mghackerlady, gnucode says: Take a look at https://darnassus.sceen.net/~hurd-web/faq/drivers/ for hardware that works with the Hurd.

<damo22>mghackerlady: i just wrote a patch that enables usb disk in the installer hopefully

<mghackerlady>sick! Have you tested it yet?

<damo22>the current status of usb support is that its all combined into one translator, the driver and the mass storage driver are one binary

<damo22>but this is not ideal, it should be separated

<damo22>its called rumpusbdisk

<damo22>i dont know how to make the stack into two pieces

<mghackerlady>how much work would need to be done to seperate them? I admittedly am not much of a kernel hacker but if it would be easyish I suppose that'd be a place to start

<damo22>its not in the kernel

<damo22>the problem is that the usb peripheral drivers expect the controller to be available on /dev/ehci etc

<damo22>within the rump /dev

<damo22>we need a way to expose the rump dev nodes to hurd's dev, and then inject them into the peripheral driver's rump filesystem

<mghackerlady>Right. I'm a bit in over my head then, considering I'm barely able to wrap my head around the whole translator concept

<damo22>i think etfs provides one direction of that

<damo22> https://man.netbsd.org/rump_etfs.3

<damo22>i guess we could write a trivfs that allows open() read() write() ioctl() on the rump dev node

<damo22>to do the reverse

<mghackerlady>Unrelated but seeing as the hurd runs well on the ThinkPad T60, I wonder if it'd work well on a [macbook 2.1](https://canoeboot.org/docs/install/macbook21.html)

<mghackerlady>they share the same chipset so it wouldn't surprise me

<damo22>most likely

<mghackerlady>I asked leah if I could buy one from her, but she was asking like 200 bucks for it and I felt that was a bit pricey. Maybe I should pick one up to run the hurd on

<damo22>newer models should be fine

<mghackerlady>it'd be at least a little ironic, a mac running the most GNU of GNU systems

<damo22>we just need to fix a few bugs with interrupts

<damo22>all my machines run coreboot

<mghackerlady>they probably would but the macbook 2.1 and its older sister the 1.1 are both able to run GNU boot

<damo22>i have one of the most powerful machines that is corebootable

<damo22>with native ram init

<damo22>unfortunately the ME is not completely removable so it doesnt qualify for gnuboot

<damo22>trying to make hurd run on this

<mghackerlady>what is it?

<damo22>thinkpad w520 and w530

<damo22>they both have 4 dimm slots so you can put 32GB ddr3 in it

<mghackerlady>Wouldn't that be a bit pointless for the hurd? IIRC the hurd doesn't do well with more than 4 GBs of ram

<damo22>no, amd64 supports more ram

<mghackerlady>huh, the more you know ig

<damo22>the i386 port is limited to 4GB address space

<mghackerlady>I didn't even know the 64 bit port was in a usable state tbh

<mghackerlady>from what I've read on the website it seemed like it was just barely working (though the last news post was a while ago)

<damo22>smp needs debugging

<damo22>but the first bug we need to fix is the rumpdisk driver not working correctly on some hw

<damo22>everything seems to work in qemu

<mghackerlady>I feel like hurd progress would be faster if we just chose a machine to get it 100% working on to use as a reference implementation of sorts

<damo22>we did, qemu

<mghackerlady>lol fair, I was thinking on real hardware tho. Developing an OS seems pretty pointless if it's not able to run on any real hardware. I guess it makes sense for a reaserch project but calling the hurd a research project seems wrong

<damo22>we need more hackers who are willing to read the source and contribute

<aaabbb>mghackerlady: developing is easier if you just have to install qemu than if you have to buy real hardware

<mghackerlady>Yeah, I suppose. I wonder if someone could implement qemu in hardware. IDK how practical that'd be but it'd be a very neat hack

<damo22>its the other way around, qemu is based on i440fx real chipset

<aaabbb>well qemu is based on real hardware

<aaabbb>yeah

<mghackerlady>huh, didn't know that

<damo22>"lspci -nn" will show you

<mghackerlady>I should stop talking out of my ass lol, I have barely any experience with any of this

<damo22>hurd should easily run on AWS for example

<damo22>not that i would recommend that platform

<mghackerlady>That's interesting. I wonder if it'd have any benefits other than being free

<damo22>youpi: the usb stack is strange, /dev/{u,e,x,o}hci is accessible in the rump kernel when the usb driver is probed, but if the mass storage driver is not compiled in, it wont probe the sd0 for example, so how does a separate process hotplug a usb device?

<damo22>dual booted i386 and amd64 hurd

<damo22>demo@zamhurd64:~$ uname -a

<damo22>GNU zamhurd64 0.9 GNU-Mach 1.8+git20250304-up-amd64/Hurd-0.9 x86_64 GNU

<damo22>the latest installer works

<gnu_srs>youpi: I think you can start mahler build queue again.

<azert>damo22: do you have any objections to the model proposed by Anti in his doctoral dissertation for usb http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf page 149 ?

<damo22>thats perfect

<damo22>does rump have ugenhc and ugen?

<azert>I think it should

<damo22>rump_server seems to provide access to the rump kernel over a unix socket?

<azert>Maybe we better use a Mach port transport

<damo22>maybe it uses the unix socket to share /dev nodes with the client?

<azert>I don’t know the details, need to look in the source

<damo22>ohh the netbsd host has /dev/ugen

<damo22>so the rump server that is compiled with ugenhc looks up /dev/ugen on the host

<azert>Yep

<damo22>so our problem now becomes exposing the real pci usb host as a /dev/ugen on the host

<damo22>i can get /dev/ugen in rumpfs

<damo22>but how do i expose that to the hurd fs

<damo22>do i need to implement a trivfs?

<azert>I think that the console already export more than one node

<azert>It doesn’t need to be called /dev/ugen

<damo22>i dont follow

<damo22>the rumpkernel that is compiled with ugenhc looks up "/dev/ugen" on the host

<azert>It’s not trivial how we want to export usb device nodes

<azert>Yes it’s /dev/ugen

<damo22>i can use rump_pub_etfs_register()

<azert>But what if you will have more than one umass drivers connected to different ugenhs running on different processes by different users ?

<damo22>are you allowed to run more than one ugenhc?

<damo22>probably you can

<azert>I think so

<damo22>i think i need to write a trivfs to expose /dev/ugen from a rumpkernel as a hurd fs node

<damo22>the rest should be easy

<damo22>youre right it doesnt have to be called ugen on hurd

<damo22>but may as well?

<azert>Sure!

<damo22>thanks azert, i think this should work

<damo22>youpi: if i have a fd = rump_sys_open() file descriptor, how do i get a mach port to that file?

<damo22>port = file_name_lookup_at (fd, 0, file, oflag, mode);

<damo22>HURD_FD_USE (ugen_fd, ???)

<damo22>is that the return code for an error?

<crupest>Is anyone here the administrator of bug-hurd mailing list? I have some trouble with sending and receiving on the list. I have posted the details about the error to bug-hurd-owner@gnu.org with my another email address. I can also repost it to any other places if the owner address is not accessable for you. Please help check if this is my problem or gnu mail server's one. Thanks!

<crupest>Also, can anyone view https://lists.gnu.org/mailman/listinfo/? I visit it and always get error "Bug in Mailman version 2.1.29". I wonder if it's because my ip is blocked.

<AlmuHS_>crupest: have you registered your email address here? https://lists.gnu.org/mailman/listinfo/bug-hurd

<crupest>Yes. Everything works last month. Until I try to fix it by unsubscribing it and no longer can re-subscribe it.

<crupest>I've put the error details in the report mail at https://paste.debian.net/1383044. If you're willing, you could have a look.

<crupest>I wonder if it's due to my misconfigured spf dns value. But other mailing lists than gnu ones work. And even if spf is wrong, shouldn't the receiving at least work?

<youpi>damo22: take care that rump fds are not unix fds

<youpi>they are not talking the io RPCs etc.

<youpi>(they are not even in the libc fd space)

<azert>youpi: would it be possible to make a library that taking a rump fd gives you back a port where you can use it as if it was a glibc fd? That is taking any rpc and translating it automatically and as best as possible to rump system calls?

<azert>Well.. can you even open a glibc fd? I think it should be something that translates a rump inode to something that can be bound to a Hurd filesystem object

IRC channel logs

2025-06-28.log