IRC channel logs

<ZhaoM>morning I would like to know which is more proper, rumpfs or ext3fs?

<damo22>rump has filesystem support i think if we port one of those we get all of them for free

<ZhaoM>I just realized maybe I will be a bit more motivated when helping implementing a new fs compared with adding storeio on the bootstrap chain

<ZhaoM>damo22: yeah I know it. I have been noticing rump for a while.

<ZhaoM>I think the idea of utilizing the rump is awesome

<damo22>i dont know how it fits with the block device, since we expose a rump based block device as a mach device,

<ZhaoM>thanks to the modularity of Hurd

<damo22>but the rumpfs probably expects block device not mach device?

<ZhaoM>so if my understanding is correct

<ZhaoM>the difference between block device and mach device is the interface functions provided?

<damo22>i think so

<ZhaoM>Do you mean rumpfs works upon a block device rather than a mach device?

<damo22>yes

<damo22>maybe it will work

<damo22>its worth a try

<ZhaoM>I see what you are thinking. Currently rumpdisk is exposed as a mach device

<ZhaoM>but rumpfs depends on a block device

<damo22>how does wd0 get exposed

<damo22>if its a block device

<damo22>it might just work

<damo22>but rump_sys_open("/dev/wd0") will look inside the /dev within rump

<damo22>so that wont work

<damo22>we need to expose the hurd node to rump

<damo22>look for "etfs"

<damo22>extra terrestrial filesystem

<damo22>it passes a OS node to rump

<ZhaoM>wait a minute. I think in the bootstrap stage we expose the hurd node (i.e. port) using bootstrap port

<ZhaoM>the bootstrap port contains the control port from the last boostrap chain node

<ZhaoM>and we can only used device_* on that port

<ZhaoM>how can we expose a hurd node

<damo22>well same way it currently boots off wd0

<damo22>we just need to pass the port that accesses the block device to a translator that mounts the filesystem and trick rump into seeing that port as a node to open

<damo22>s/rump/rumpfs_ext4

<damo22>or whatever

<ZhaoM>I think this is what we have now, isn't it?

<damo22>no

<damo22>we are not using rumpfs

<damo22>we use rumpdisk

<damo22>to provide block device

<ZhaoM>I mean we now trick ext2fs into seeing that port as a node to open

<damo22>we can chain that to another new translator that mounts any kind of filesystem

<damo22>oh probably, yes

<damo22>we have ideal setup

<damo22>controller code separate from filesystem

<damo22>so we can attach any filesystem

<damo22>usb is not like this

<ZhaoM>thanks for the info sharing :). I will give rumpfs a try

<ZhaoM>ah yes I'm quite curious about the rumpusbdisk

<ZhaoM>I think the website mentioned that there is an issue about interrupt number

<damo22>usb stack is stuck with just mass storage driver currently

<damo22>so you cant attach different peripherals

<damo22>ideally it would be split

<damo22>controller + peripheral drivers

<damo22>ZhaoM: can you point me to the doc on usb? i might need to update it

<ZhaoM> https://darnassus.sceen.net/~hurd-web/hurd/rump/rumpusbdisk/

<ZhaoM>oh so the website is a bit out-of-date

<ZhaoM>a small instruction about how to give rumpusbdisk a try will be very useful

<ZhaoM>:)

<azert>I don’t agree that for USB the controller and the device drivers are not separated, they are quite well defined

<azert>It’s just that USB is a very general high level interface, cannot be compared to block devicea

<azert>The api is a mess https://www.beyondlogic.org/usbnutshell/usb1.shtml looks more like a network stack!

<azert>Maybe something like BPF could be exploited as a flexible api to connect an USB controller to device drivers

<azert>BPF was specifically intended for high performance user space drivers

<azert>Things like filtering at the controller level and raw packets..

<damo22>azert: i just meant our current implementation is an all-in-one controller+mass storage translator

<damo22>but i dont know how to separate them such that the controller sits on a hurd dev node such as /dev/ehci and *something* connects to that to provide /dev/sd* for usb sticks or other nodes for other devices

<damo22>i think the rump kernel that exposes the controller must have all the peripheral drivers linked in, so that it can probe all the devices and hotplug them to the correct driver

<damo22>so the "usb" translator would know about everything connected to usb

<damo22>currently that is the case, but we only have mass storage linked

<damo22>unless every driver is rewritten to support some api that sits on the usb controller node

<damo22>i wont be doing that

<youpi>isn't there already some software layer?

<youpi>they are in separate objects

<damo22>i think the host controller driver detects when something attaches to the bus, but if there is no peripheral driver linked it ignores the device

<damo22>how do you link the driver just in time for it to be probed?

<damo22>could it be a dynamically resolved symbol?

<youpi>we could link some bridge code to other translators

<damo22>i think rump exposes /dev/{u,e,o,x}hci

<damo22>but i dont know how the peripheral drivers work

<damo22>maybe they just eg open(/dev/ehci)

<civodul>hello!

<civodul>are there known payloads that can make ‘rpctrace’ hang?

<youpi>civodul: iirc fork pose problem

<youpi>there were some issues with gsync as well, I don't rember if that was solved

<civodul>oh i see, it must be fork then

<civodul>thanks!

<civodul>although hmm, also hangs with ‘shepherd --version’, which doesn’t fork

<civodul>i’ll take another look later

<gnucode>I kind of wonder how hard it would be to make Mach a POSIX process...

<gnucode>It would be wild to run the Hurd on top of Linux as just a regular process. It might help with debugging various things too.

<Gooberpatrol_66>gnucode https://darnassus.sceen.net/~hurd-web/open_issues/mach_on_top_of_posix/

<gnucode>Gooberpatrol_66: Yeah, I've read that one before.

<azert>gnucode: the people working on darling have a Linux module implementing much of their flavor of Mach

<azert>Or a Linux process, in the latest iteration

<azert>darlingserver

<azert>That said, what’s the point?

<azert>This works on Linux and Windows, not sure about FreeBSD and probably not NetBSD https://github.com/wcooley/usbrevue/tree/master

<azert>It has tools to receive and send usb packet streams

<azert>If it was working on netbsd probably the Hurd could use the interfaces to implement user space drivers

<azert>It uses a version of libpcap for usb

<azert> https://github.com/JohnDMcMaster/usbrply

<azert>I wonder if this gets ported to netbsd https://man.freebsd.org/cgi/man.cgi?query=usbdump&sektion=8

IRC channel logs

2025-04-15.log