On 26/10/15 01:05, Olaf Buddenhagen wrote:
What exactly are you trying to isolate faults from? If the bottom or
top layer of the USB stack fails, applications will still fail. Ok,
if the top layer has no PCI access, then maybe it can't misprogram the
DMA controller. But that would be a
Hi,
On Tue, Oct 20, 2015 at 02:22:21AM +, Antti Kantee wrote:
> On 19/10/15 10:26, Olaf Buddenhagen wrote:
> >Fault isolation is also a concern -- though not the primary goal of
> >the Hurd architecture.
>
> What exactly are you trying to isolate faults from? If the bottom or
> top layer
Hi,
On Sat, Oct 17, 2015 at 01:16:38PM +, Antti Kantee wrote:
> On 16/10/15 16:17, Olaf Buddenhagen wrote:
> Ok, so you'd decide how to limit the visibility and arbitrate bus
> access in your PCI backend
Yes, I believe that's the cleanest approach.
(Not sure whether there is actually
On 19/10/15 10:26, Olaf Buddenhagen wrote:
Not sure how much pluggability you would gain [...] meaning if you
could use alternative implementations.
I don't expect to be using alternative implementations; but separation
of concerns can improve flexibility in other ways too...
Fault isolation
On 16/10/15 16:17, Olaf Buddenhagen wrote:
Let's start with the *ideal* architecture we would like to have. There
should be a PCI server process, which presents device files for every
PCI device present; along with a libpciaccess backend which can be
pointed at any of these device files, giving
Hi,
On Thu, Oct 15, 2015 at 01:28:24AM +, Antti Kantee wrote:
> So do you want to implement your own drivers on top of libusb and use
> the rump kernel only for the host controller and device-independent
> USB support, or do you want to actually use the USB device-level
> drivers too (mass
On 16/10/15 16:56, Robert Millan wrote:
El 15/10/15 a les 03:03, Bruno Félix Rezende Ribeiro ha escrit:
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
El 15/10/15 a les 03:03, Bruno Félix Rezende Ribeiro ha escrit:
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()
On 15/10/15 01:03, Bruno Félix Rezende Ribeiro wrote:
uhci0 at pci0 dev 2 function 0: vendor 8086 product 24c2 (rev. 0x01)
uhci0: interrupting at pausebreak
usb0 at uhci0: USB revision 1.0
uhub0 at usb0: vendor 8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports
Hello Robert!
Em Wed, 30 Sep 2015 22:37:50 +0200
Robert Millan escreveu:
> I suggest you export RUMP_VERBOSE=2 to get verbose output from the
> Rump kernel.
Thank you for the suggestion. Here is the output:
libusb: 0.00 debug [libusb_init] libusb-1.0.9
Copyright (c)
On 15/10/15 01:13, Bruno Félix Rezende Ribeiro wrote:
If you do need libusb, adding a ugen component shouldn't be too
difficult, though.
How could I help with that? Is it worth?
I don't know if it's worth it because I don't know what you want to do! ;)
It's probably enough to create a
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
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:
Hello, GNU Hurd hackers!
Based on Robert Millan's mplayer rump patch, I was able to make a
patch to successfully build libusb-1.0 on Hurd linking it to librump.
The patch is attached. To try it, save the patch file in the current
working directory and from there follow these steps:
$ su -c
14 matches
Mail list logo