Re: Shortest path to significant improvement in hardware support
Hi, On Tue, Sep 29, 2015 at 06:31:01AM -0300, Bruno Félix Rezende Ribeiro wrote: > From that perspective I'm looking for the most straightforward way to > get hardware working on Hurd [...] > After some thought I came to the conclusion that the way to achieve > these requirements is to patch core libraries like libusb to use > librump directly, analogously to what Robert Millan did originally for > mplayer and sound support. I don't think that's a viable approach for most use cases: it requires all applications using any of the Rump drivers to run with full hardware access. That's like MS DOS -- the exact opposite of a microkernel architecture :-) While theoretically there are ways to avoid that (see exokernel), that would require considerably *more* changes than running Rump instances as Hurd servers. -antrik-
Re: libusb+librump patch
On 30/09/15 20:37, Robert Millan wrote: Hi Bruno, El 30/09/15 a les 06:57, Bruno Félix Rezende Ribeiro ha escrit: To test the built library, build the example application and run it. $ cd examples && make $ su -c './listdevs' Now, here is the problem: When I run 'listdevs' with no USB device connected to the box I get: libusb: 0.00 debug [libusb_init] libusb-1.0.9 libusb: 1.87 debug [usbi_add_pollfd] add fd 4 events 1 libusb: 1.87 debug [libusb_init] created default context libusb: 1.88 debug [libusb_get_device_list] libusb: 1.88 debug [obsd_get_device_list] libusb: 1.91 debug [libusb_exit] libusb: 1.91 debug [libusb_exit] destroying default context libusb: 1.92 debug [usbi_remove_pollfd] remove fd 4 And thus no device is listed, as expected. However, if I plug in any USB device I get the following message after the first (libusb_init) line: WARNING: 1 error while detecting hardware; check system log. It means that this message is produced by the 'rump_init' function. The other debug messages are the same, and thus no device is listed --- what's not right. Do you have any idea on what's going on? Any points to facts, procedures, concepts or documentation will be highly appreciated. So you are wanting libusb to work against a rump kernel? A rump kernel does not, at least currently and AFAIR/AFAIK, provide ugen, so that won't work now. I would expect things to fail at trying to open /dev/ugen[n]. If you do need libusb, adding a ugen component shouldn't be too difficult, though. (but I sort of hate ugen ;) I suggest you export RUMP_VERBOSE=2 to get verbose output from the Rump kernel. Maybe 1 is enough. At least I don't recall any value!=0 being special. OTOH I think this part of your patch: + #define RUMP_SYS_OPEN + #define RUMP_SYS_CLOSE + #define RUMP_SYS_IOCTL + #define RUMP_SYS_READWRITE is a bit dangerous. It would break any (current or future) usage of open() / close() / etc in that file which is not related to USB device nodes. Yea, true. What sort of general architecture are you planning in the Hurd case?
Re: libusb+librump patch
Hi Bruno, El 30/09/15 a les 06:57, Bruno Félix Rezende Ribeiro ha escrit: To test the built library, build the example application and run it. $ cd examples && make $ su -c './listdevs' Now, here is the problem: When I run 'listdevs' with no USB device connected to the box I get: libusb: 0.00 debug [libusb_init] libusb-1.0.9 libusb: 1.87 debug [usbi_add_pollfd] add fd 4 events 1 libusb: 1.87 debug [libusb_init] created default context libusb: 1.88 debug [libusb_get_device_list] libusb: 1.88 debug [obsd_get_device_list] libusb: 1.91 debug [libusb_exit] libusb: 1.91 debug [libusb_exit] destroying default context libusb: 1.92 debug [usbi_remove_pollfd] remove fd 4 And thus no device is listed, as expected. However, if I plug in any USB device I get the following message after the first (libusb_init) line: WARNING: 1 error while detecting hardware; check system log. It means that this message is produced by the 'rump_init' function. The other debug messages are the same, and thus no device is listed --- what's not right. Do you have any idea on what's going on? Any points to facts, procedures, concepts or documentation will be highly appreciated. I suggest you export RUMP_VERBOSE=2 to get verbose output from the Rump kernel. OTOH I think this part of your patch: + #define RUMP_SYS_OPEN + #define RUMP_SYS_CLOSE + #define RUMP_SYS_IOCTL + #define RUMP_SYS_READWRITE is a bit dangerous. It would break any (current or future) usage of open() / close() / etc in that file which is not related to USB device nodes. Best regards -- Robert Millan
Re: Shortest path to significant improvement in hardware support
On Tue, Sep 29, 2015 at 06:31:01AM -0300, Bruno Félix Rezende Ribeiro wrote: > This way we don't have to make the settlement of wonders about "the > (elegant and powerful) true Hurdish way" become a dependency of the > actual hardware support the Hurd community needs so badly. > > What are your thoughts on that? I'm completely opposed to this approach. The Hurd has no other purpose than showing what its elegant and powerful way can provide. I for one really don't care about getting a user base, unless that user base exists precisely because of the features of the system. -- Richard Braun
