<damo22>gnucode: anything on bug-hurd mentioning rump is about using netbsd drivers in userspace. I don't know what you mean about libc <damo22>we need to refactor some of rump disk drivers so that it can be linked separately for ide and ahci <damo22>i havent had time to look at it at all ***devmsv_ is now known as devmsv
<Zopolis4>How feasible would it be to use linux kernel drivers/firmware modules as Hurd servers? (i.e. like Sawmill Linux) <Zopolis4>I ask because it seems to make sense to try to minimize the amount of duplicate work being done on open-source drivers, but having to make significant non-automated source code changes means things will quickly fall out of sync with upstream, but an emulation layer with large overhead feels like it misses the point of a microkernel. <damo22>we already have a small library that exposes an emulated mach device called libmachdev we just need to plug in some working drivers <damo22>rump has tons of stuff we havent even looked at yet <damo22>the benefit of rump is that its a clone of netbsd upstream <damo22>no need to create a wrapper of sorts, it comes with it <damo22>im not advocating to write new drivers from scratch <damo22>there is a small problem that the main developer of rump is no longer maintaining it, and netbsd people are kind of ignoring it and only making changes to stop breakage <habu>I thought that rump was used by netBSD people to perform testing <habu>if that's the case then it will be at least kept alive <damo22>i think thats the only reason they havent removed it completely, is that its useful to run unit tests on the kernel <damo22>maybe someone should fork netbsd kernel and make gplv2-only improvements that includes drivers from Linux <habu>damo22 seems like a bad idea <habu>what about patches, are they happy to apply patches if useful? <damo22>yeah but no one can reuse linux drivers <damo22>hurd is agnostic to drivers' licensing because its running in userspace <habu>I am not sure about that <habu>anyone could run the driver, but you wouldn't accept them in your git repository, right? <damo22>habu: you can compile a translator as a statically linked binary that is proprietary software and it could drive hardware in hurd <habu>I agree I'm not arguing about that <damo22>we wouldnt put it into hurd git repo, but it could function <damo22>ideally, we have the stability of netbsd kernel API, with all the drivers from Linux as libraries <habu>imagine someone ports linux usbfs to hurd, doesn't seems like an insurmontable amount of work <habu>then you would have the keyboard driver gpl2 out of the kernel git <damo22>we just need to implement a set of RPCs that allows the controller translator to communicate with the devices <habu>what do you mean by that? <damo22>but i dont think anyone has tried to compile and link it to provide a translator <habu>cannot you plug it in the same way you do for the ATA bus? <habu>what did you mean by set of RPCs? <damo22>but it may need to enumerate some devices and store that list somewhere dynamically <damo22>there may be some structures needed <habu>that will happen inside the rump kernel, right?N <habu>netbsd already does that <damo22>yeah but we want to access them in hurd <damo22>so they need to be exposed as nodes <habu>I think that on NetBSD is as boring as /dev/usb[0-9] nodes <damo22>i need to try it and see what happens <damo22>but i dont know how you implement usb functionality, we could use the umass storage as a device <damo22>and it could implement open/write/read <habu>I agree that it's more complex <damo22>but in general case, usb is complex <habu>let's say you just port /dev/usb[0-9], that would be enough to run libusb drivers <habu>if you want to part all the other drivers as well, there is a set of nodes for each one of them <habu>uhid and storage seems like a must <damo22>but we should expose /dev/usbX and make uhid and storage talk to the nodes in hurd instead of in netbsd land <damo22>so that hurd can manage the controllers as a translator <damo22>then you just attach more translators for storage and uhid <habu>I understand that that would require having the RPCs designed to match the NetBSD internal api? <damo22>unless the rump storage driver can attach to a node in userspace <habu>I would try porting just /dev/usbX and see how far one can go with just libusb drivers <youpi>Zopolis4: there used to be the dde project, but it was difficult to maintain <damo22>habu: that should be almost trivial <habu>problem is that also libusb is just gpl v2.1 <damo22>every process that runs can have a different license <habu>I think that libusb needs the ugen driver <habu>that corrisponds to /dev/ugenN.EE <habu> ugen - USB generic device support <damo22>looks like all you need is ioctl calls to use USB generically <damo22>ugenhc_user.c needs to be compiled <damo22>rumpcomp_ugenhc_ioctl is otherwise a missing symbol <habu>Antti was suggesting two servers, the top one exporting ugen <habu>libusb could directly access that server <habu>then a second server (eg mass storage) can use ugenhc to run at the bottom of the top one <habu>hence serving other device drivers provided by NetBSD <habu>I think that this should be doable <habu>of course, the more hurdish way would be to export devices on a filesystem the way the pci arbiter export pci devices, providing fine-grain per-user, per-session, etc. permission management over USB access <habu>for instance, if an hacker would implement a very hurdish usb-arbiter, and this would expose usb devices in a way compatible to NetBSD ugen, rump drivers could still be used on top of it using the ugenhc mechanism <habu>of course, usb-arbiter could in turn be built to be run on top of rump-usb and ugen