On 08/11/15 20:39, Robert Millan wrote:
El 08/11/15 a les 20:45, Da Zheng ha escrit:
Hello Robert,
Sure, I have no problem with the license.
Excellent!
I have thus merged the remaining bits of GNU/Hurd port which included your code:
https://github.com/rumpkernel/pci-userspace/commit/a92
On 02/11/15 20:36, Robert Millan wrote:
El 13/09/15 a les 14:55, Antti Kantee ha escrit:
On 13/09/15 09:33, Robert Millan wrote:
Hi Antti
El 31/08/15 a les 21:05, Antti Kantee ha escrit:
On 31/08/15 14:30, Robert Millan wrote:
El 31/08/15 a les 16:04, Robert Millan ha escrit:
I had some
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 maliciou
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 i
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 a
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 (curre
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 compo
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 wit
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
On 23/09/15 21:49, Olaf Buddenhagen wrote:
IMO the right way to do device drivers in a hosted environment is to
have one entity which decides which servers see which devices and just
let the servers attach to all devices they see.
From what I gathered from Robert's and your explanations, it so
On 23/09/15 21:25, Robert Millan wrote:
I'm also happy to apply a patch where
MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel
userspace code, if you (or someone else) want to send one in another PR.
I think that would be nice having, but unfortunately I lack the spare
time at
On 19/09/15 08:52, Robert Millan wrote:
[Adding rumpkernel-users]
El 19/09/15 a les 01:21, Olaf Buddenhagen ha escrit:
Is there no way to limit the probing to a particular device, though? In
the long run, it really seems cleaner to tell the driver, "please try to
serve this device", rather tha
On 13/09/15 09:33, Robert Millan wrote:
Hi Antti
El 31/08/15 a les 21:05, Antti Kantee ha escrit:
On 31/08/15 14:30, Robert Millan wrote:
El 31/08/15 a les 16:04, Robert Millan ha escrit:
I had some trouble with the .BEGIN approach, but the MAKEFILEINC one
works
perfectly. I'm attach
On 31/08/15 14:30, Robert Millan wrote:
El 31/08/15 a les 16:04, Robert Millan ha escrit:
I had some trouble with the .BEGIN approach, but the MAKEFILEINC one
works
perfectly. I'm attaching a patch.
Actually, please use this one, which includes .ifdef not to break other
platforms ;-)
Yea I'l
On 30/08/15 15:10, Robert Millan wrote:
But that's not what you were asking for. I don't know what's wrong
based on the above. Can you paste the entire Makefile and command line?
Makefile is attached (in my tree, this is pci-userspace/src-gnu/Makefile)
Command-line is:
../../buildrump.sh/ob
On 30/08/15 10:22, Robert Millan wrote:
I figured out how to generate those off-tree and wrote a small Makefile
snippet to do it:
experimentalUser.c experimental_U.h:
echo '#include ' \
| gcc -E -x c - -o - \
| mig -cc cat - /dev/null -subrprefix __ \
-user ex
On 24/08/15 21:24, Robert Millan wrote:
El 16/08/15 a les 15:07, Antti Kantee ha escrit:
Can you submit the patches against NetBSD tools directly to NetBSD?
It's hard to test that one didn't break any platform when mucking
around with the crosstools, so it never hurts to have t
On 24/08/15 21:24, Robert Millan wrote:
El 16/08/15 a les 15:07, Antti Kantee ha escrit:
Can you submit the patches against NetBSD tools directly to NetBSD?
[snip]
Here:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50166
The buildrump.sh bit, again, please submit as a pull
On 16/08/15 20:33, Robert Millan wrote:
El 16/08/15 a les 15:14, Antti Kantee ha escrit:
>> * It includes code from other people under GPLv2; I'm not sure if
this may be an issue wrt licensing
>>policy of Rump as this is only targetted at the pci-userspace
module. I
On 16/08/15 10:48, Robert Millan wrote:
Hi,
Here's the first patch of my port of Rump to GNU/Hurd. It includes the basic
system detection stuff.
Applied the src-netbsd bits.
Can you submit the buildrump.sh part as a pull req on github?
On 16/08/15 10:51, Robert Millan wrote:
Hi,
Apparently this routine only wants the Rump version of when
building with Rump namespace, but it includes the header unconditionally.
This is usually harmless as almost everyone has , but GNU/Hurd
doesn't. So my patch just moves it into Rump protect
On 16/08/15 11:09, Robert Millan wrote:
Hi,
This patch adds GNU/Hurd support to pci-userspace. Some notes:
* It uses libpciaccess to query/modify the PCI config stuff. This part of the
code is pretty
generic, perhaps this approach can be useful to other ports?
perhaps
* It includes cod
On 16/08/15 10:56, Robert Millan wrote:
Hi,
GNU/Hurd doesn't have PATH_MAX or MAXHOSTNAMELEN (arbitrarily long strings can
be used). Since attempting to replace every instance of static allocation with
dynamic buffer management would make for a very intrusive patch, I'm proposing
to just define
23 matches
Mail list logo
