Re: Full-time developer available

[Robert Millan]

El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
> > That said I think Rump opens up a lot of interesting possibilities.
> > I'm glad to see interest in that. Which particular area do you have
> > in mind?
>
> I'm interested in USB support.  I'd like to aim mass storage devices at
> first.

For USB using Rump, I think most of the pieces exist already. Rump implements
the ugenhc NetBSD API, which is already supported by libusb, so if you want
to support all libusb-aware applications, I think you'd just need something
like:

(cups|sane|whatever) ---> libusb ----> /dev/rumpusb (in Hurd VFS) ----> your 
translator ----> librump ----> /dev/ugenhc

Rump API is very straightforward. It's basically POSIX with a few translation
gimmicks. E.g.

        int fd = rump_sys_open("/dev/ugenhc", RUMP_O_RDWR);
        if (fd == -1)
          error(1, rump_errtrans_rump2host(errno), "rump_sys_open");

> > I was planning to ask for advice on how to make a "/dev/audio ->
> > librump0" translator sometime soon. I've written similar a glue layer
> > for Linux [1], but I'm missing a lot of knowledge when it comes to
> > the Hurd way of doing this (like, how to service ioctls without
> > libtrivfs?).
>
> I also need the same kind of advice.  I think a discussion about this
> subject will help both of us and also other people who are struggling to
> get an in-depth understanding of Hurd's ways.

Yes. This (ioctl handling) was the main blocker when I attempted an audio
translator. Some advice would be very welcome.

The other problem I had is that I don't know how to make a single translator
service two separate device nodes (obviously you don't want to start a
different Rump instance for /dev/audio, /dev/mixer, etc as they would fight
each other trying to access the same hardware). At least for audio this is
a lesser problem though, as /dev/audio is useful as a standalone node.

BR & happy hacking

--
Robert Millan