Re: libusb+librump patch

[Antti Kantee]

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.000000 debug [libusb_init] libusb-1.0.9
> >    libusb: 1.870000 debug [usbi_add_pollfd] add fd 4 events 1
> >    libusb: 1.870000 debug [libusb_init] created default context
> >    libusb: 1.880000 debug [libusb_get_device_list]
> >    libusb: 1.880000 debug [obsd_get_device_list]
> >    libusb: 1.910000 debug [libusb_exit]
> >    libusb: 1.910000 debug [libusb_exit] destroying default context
> >    libusb: 1.920000 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?