[Top][All Lists]

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

Re: libusb+librump patch

From: Antti Kantee
Subject: Re: libusb+librump patch
Date: Wed, 30 Sep 2015 20:57:06 +0000

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)

   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

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

Yea, true.

What sort of general architecture are you planning in the Hurd case?

reply via email to

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