bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shortest path to significant improvement in hardware support


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]