IRC channel logs


back to list of logs

<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>and wd
<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
<damo22>yes i think so too
<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>unless its gplv2
<damo22>hurd is agnostic to drivers' licensing because its running in userspace
<damo22>as a process
<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>rump already has usb
<damo22>we just need to implement a set of RPCs that allows the controller translator to communicate with the devices
<damo22>i think
<damo22>make it fit together
<habu>what do you mean by that?
<damo22>rump has usb functionality
<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?
<damo22>yes its pci
<habu>exactly, same for usb
<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
<habu>why that?
<damo22>so that hurd can manage the controllers as a translator
<damo22>using the rump usb driver
<habu>that would be cool
<damo22>then you just attach more translators for storage and uhid
<damo22>to the hurd nodes
<habu>I understand that that would require having the RPCs designed to match the NetBSD internal api?
<damo22>maybe, i dont know
<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
<habu>LGPL v2.1
<habu>is it an issue?
<damo22>not really i think
<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>I just checked
<damo22>what is ugen?
<habu>     ugen - USB generic device support
<damo22>usb generic?
<damo22>looks like all you need is ioctl calls to use USB generically
<damo22>ugenhc_user.c needs to be compiled
<damo22>its not in the librump*
<damo22>it implements the ioctl
<damo22>rumpcomp_ugenhc_ioctl is otherwise a missing symbol
<Zopolis4>youpi: thanks, I'll take a look
<habu>damo22 I found this interesting discussion on the ML :
<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