|
From: | Robert Millan |
Subject: | Re: Shortest path to significant improvement in hardware support |
Date: | Tue, 29 Sep 2015 22:56:59 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
Hi Bruno! El 29/09/15 a les 11:31, Bruno Félix Rezende Ribeiro ha escrit:
My main goal working on Hurd is to get more people to use the GNU system, so we can achieve critical mass to make the system develop at an acceptably pace. In order to solve this problem it's necessary to fix the most prominent issue preventing people from migrating to it, that is, its lack of hardware support. Thus, in order to form an wider user-base as soon as possible, we need to improve Hurd's hardware support using the shortest (thus fastest) path available. For that goal's sake alone, in principle, it doesn't matter the technicalities of a particular implementation, as long as it works for the majority of use cases, it's quick to implement and easy to maintain. From that perspective I'm looking for the most straightforward way to get hardware working on Hurd --- primarily USB as it seems that it along with sound (Robert Millan's work) is what people need most. 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. 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?
When you say USB is one of the things people need most, are you thinking on any particular usage of USB? I.e. any device class in particular? A combination of them? I recall in earlier talk about USB we discussed about possible design options my understanding from that discussion is that there were basically three possible desirable goals: #1 multiplexing (multiple processes simultaneously using USB devices) #2 authorization (allowing unprivileged users without I/O capability) #3 compatibility with non-Rump users (e.g. CUPS or SANE) Note that if you simply patch libusb to start a Rump instance all by itself, you're giving up on goals #1 and #2. However you retain goal #3. Is this something you were already contemplating? Note that retaining goals #1 and #2 is not difficult, it just means adding a translator process to sit in-between and forward ioctls to Rump. The upside is that this is *exactly* the same thing that is missing for sound, so one could kill two birds with a single stone this way. -- Robert Millan
[Prev in Thread] | Current Thread | [Next in Thread] |