Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-11-02 Thread Robert Millan
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 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'll probably add something like that, but need to think about it
>>> a bit more first, namely why didn't I do that originally.  Either I
>>> was being stupid, or there was some actual reason.  I'll let you
>>> know.  Use the .BEGIN way for now if you can make it work (or drag the
>>> local patch for a few days).
>>
>> Hereby, a kind reminder :)
> 
> Yea it's being worked on.  I want to split the bus dma/space routines out of 
> libpci, since they shouldn't be there, plus add some necessary parameters to 
> the hypercalls (e.g. memory alignment/boundary requirements).  I think it's 
> good to get that done before you start depending on anything.  So I'll just 
> bundle the Makefile change in with the other changes.

Just to make sure you don't forget ;-)

Kindly,

-- 
Robert Millan



Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-11-02 Thread Antti Kantee

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 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'll probably add something like that, but need to think about it
a bit more first, namely why didn't I do that originally.  Either I
was being stupid, or there was some actual reason.  I'll let you
know.  Use the .BEGIN way for now if you can make it work (or drag the
local patch for a few days).


Hereby, a kind reminder :)


Yea it's being worked on.  I want to split the bus dma/space routines out of 
libpci, since they shouldn't be there, plus add some necessary parameters to 
the hypercalls (e.g. memory alignment/boundary requirements).  I think it's 
good to get that done before you start depending on anything.  So I'll just 
bundle the Makefile change in with the other changes.


Just to make sure you don't forget ;-)


The MAKEFILEINC bit is in there now:
https://github.com/rumpkernel/src-netbsd/blob/kernel-src/sys/rump/dev/lib/libpci/Makefile#L46-L49

I didn't get around to the rework, so I thought I'd just put that one 
fix in there for now.




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-09-13 Thread Robert Millan

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 attaching a patch.


Actually, please use this one, which includes .ifdef not to break other
platforms ;-)


Yea I'll probably add something like that, but need to think about it a bit 
more first, namely why didn't I do that originally.  Either I was being stupid, 
or there was some actual reason.  I'll let you know.  Use the .BEGIN way for 
now if you can make it work (or drag the local patch for a few days).


Hereby, a kind reminder :)

--
Robert Millan



Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-09-13 Thread Antti Kantee

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 attaching a patch.


Actually, please use this one, which includes .ifdef not to break other
platforms ;-)


Yea I'll probably add something like that, but need to think about it
a bit more first, namely why didn't I do that originally.  Either I
was being stupid, or there was some actual reason.  I'll let you
know.  Use the .BEGIN way for now if you can make it work (or drag the
local patch for a few days).


Hereby, a kind reminder :)


Yea it's being worked on.  I want to split the bus dma/space routines 
out of libpci, since they shouldn't be there, plus add some necessary 
parameters to the hypercalls (e.g. memory alignment/boundary 
requirements).  I think it's good to get that done before you start 
depending on anything.  So I'll just bundle the Makefile change in with 
the other changes.




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-31 Thread Antti Kantee

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'll probably add something like that, but need to think about it a 
bit more first, namely why didn't I do that originally.  Either I was 
being stupid, or there was some actual reason.  I'll let you know.  Use 
the .BEGIN way for now if you can make it work (or drag the local patch 
for a few days).




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-31 Thread Antti Kantee

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/obj/tooldir/rumpmake dependall


Ah.  That happens because the make which needs experimentalUser.c does 
not see the rule in the current Makefile (everything in SUBDIR is run in 
another make).


The easy way to fix it is to add the following line to the Makefile 
containing the rule and SUBDIRs:


.BEGIN: experimentalUser.c

It's a slightly weird way to use make, though.

I wonder if rump/dev/lib/libpci should look at a variable to decide if 
it needs to include some further definitions, e.g. 
RUMPCOMP_MAKEFILEINC.compname.  That would solve both LDFLAGS and this 
issue.  "leave it to the client"




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-31 Thread Robert Millan

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 ;-)

--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
===
--- rumpkernel-0~20150715.orig/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile	2015-08-15 12:10:33.0 +0200
+++ rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile	2015-08-31 16:19:58.220017146 +0200
@@ -41,6 +41,10 @@
 # XXX: messy
 .undef RUMPKERN_ONLY
 
+.ifdef RUMPCOMP_MAKEFILEINC.rumpdev_pci
+.include "${RUMPCOMP_MAKEFILEINC.rumpdev_pci}"
+.endif
+
 .include "${RUMPTOP}/Makefile.rump"
 .include 
 .include 


Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-31 Thread Robert Millan

El 31/08/15 a les 13:07, Antti Kantee ha escrit:

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/obj/tooldir/rumpmake dependall


Ah.  That happens because the make which needs experimentalUser.c does not see 
the rule in the current Makefile (everything in SUBDIR is run in another make).

The easy way to fix it is to add the following line to the Makefile containing 
the rule and SUBDIRs:

.BEGIN: experimentalUser.c

It's a slightly weird way to use make, though.

I wonder if rump/dev/lib/libpci should look at a variable to decide if it needs to 
include some further definitions, e.g. RUMPCOMP_MAKEFILEINC.compname.  That would solve 
both LDFLAGS and this issue.  "leave it to the client"


I had some trouble with the .BEGIN approach, but the MAKEFILEINC one works
perfectly. I'm attaching a patch.

--
Robert Millan
Index: rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
===
--- rumpkernel-0~20150715.orig/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
+++ rumpkernel-0~20150715/buildrump.sh/src/sys/rump/dev/lib/libpci/Makefile
@@ -41,6 +41,8 @@ CPPFLAGS+=		${RUMPCOMP_CPPFLAGS.rumpdev_
 # XXX: messy
 .undef RUMPKERN_ONLY
 
+.include "${RUMPCOMP_MAKEFILEINC.rumpdev_pci}"
+
 .include "${RUMPTOP}/Makefile.rump"
 .include 
 .include 


Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-30 Thread Robert Millan

El 16/08/15 a les 13:09, Robert Millan 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. In any 
case if you
   think it's an issue let me know and we'll try to find a solution:
   ...
   - experimentalUser.c is an automatically generated file copied from the Hurd 
build tree. I
 would welcome some help from MIG experts on how to do this in a more 
elegant way.


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 mach/experimental.defs' \
| gcc -E -x c - -o - \
| mig -cc cat - /dev/null -subrprefix __ \
-user experimentalUser.c \
-server /dev/null \
-header experimental_U.h

However no matter how I try to tell rumpmake the experimentalUser.c build 
instructions, it seems uncapable
of doing so:

nbmake[1]: don't know how to make experimentalUser.c. Stop

I've tried using absolute paths to rule out that it's a cwd problem, but still 
same error.

Any idea what I'm doing wrong?

--
Robert Millan



Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-30 Thread Antti Kantee

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 mach/experimental.defs' \
 | gcc -E -x c - -o - \
 | mig -cc cat - /dev/null -subrprefix __ \
 -user experimentalUser.c \
 -server /dev/null \
 -header experimental_U.h

However no matter how I try to tell rumpmake the experimentalUser.c
build instructions, it seems uncapable
of doing so:

nbmake[1]: don't know how to make experimentalUser.c. Stop

I've tried using absolute paths to rule out that it's a cwd problem, but
still same error.

Any idea what I'm doing wrong?


One thing you are doing wrong is creating a rule which creates two 
targets.  If both targets happen to be made in parallel, you usually get 
corrupt output.  So e.g. make the .h depend on the .c (or simply omit it 
entirely if nothing on the chain depends on the .h).


Might also consider replacing gcc with ${CC}?

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?




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-30 Thread Robert Millan

Hi Antti

El 30/08/15 a les 16:44, Antti Kantee ha escrit:

One thing you are doing wrong is creating a rule which creates two targets.  If 
both

 targets happen to be made in parallel, you usually get corrupt output. So 
e.g. make
 the .h depend on the .c (or simply omit it entirely if nothing on the chain 
depends on the .h).

Just omitted it then, thanks.


Might also consider replacing gcc with ${CC}?


Sure.


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/obj/tooldir/rumpmake dependall

Many thanks

--
Robert Millan
RUMPTOP= ${TOPRUMP}

RUMPCOMP_USER_SRCS.rumpdev_pci= pci_user-gnu.c experimentalUser.c
RUMPCOMP_USER_PATH.rumpdev_pci:=${.PARSEDIR}
RUMPCOMP_USER_CPPFLAGS.rumpdev_pci:=-I${.PARSEDIR}
RUMPCOMP_CPPFLAGS.rumpdev_pci:= -I${.PARSEDIR}

experimentalUser.c:
echo '#include mach/experimental.defs' \
| ${CC} -E -x c - -o - \
| mig -cc cat - /dev/null -subrprefix __ \
-user experimentalUser.c \
-server /dev/null \
-header experimental_U.h

.export RUMPCOMP_USER_SRCS.rumpdev_pci
.export RUMPCOMP_USER_PATH.rumpdev_pci
.export RUMPCOMP_USER_CPPFLAGS.rumpdev_pci
.export RUMPCOMP_CPPFLAGS.rumpdev_pci

.include ${RUMPTOP}/dev/Makefile.rumpdevcomp

.for pcidev in ${RUMPPCIDEVS}
SUBDIR+= ${RUMPTOP}/dev/lib/lib${pcidev}
.endfor

.include bsd.subdir.mk


Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-16 Thread Antti Kantee

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 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. In any 
case if you
   think it's an issue let me know and we'll try to find a solution:
   - intrthread() is heavily based on intloop() from hurd/libddekit/interrupt.c
   - experimentalUser.c is an automatically generated file copied from the Hurd 
build tree. I
 would welcome some help from MIG experts on how to do this in a more 
elegant way.
   - intr.h was just copied from GNU Mach source tree (I don't think it is 
copyright-significant
 though).


I'm not worried about GPL, but I am worried about someone using GPL 
accidentally when they did not intend to.  It's better if the code can 
offered under LGLP, but not a requirement.  One option would be to put 
Hurd support under gpl/src-hurd.  Or just be very explicit about the 
licensing both in LICENSE and README.



Can you make sure your code is properly formatted (space vs. tab). 
Also, there's at least one copypasted comment which is no longer valid.




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-16 Thread Antti Kantee

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. In any case if you
 think it's an issue let me know and we'll try to find a solution:
 - intrthread() is heavily based on intloop() from
hurd/libddekit/interrupt.c
 [...]
 
  I'm not worried about GPL, but I am worried about someone using GPL
accidentally when they did not intend to.  It's better if the code can
offered under LGLP, but not a requirement.  One option would be to put
Hurd support under gpl/src-hurd.  Or just be very explicit about the
licensing both in LICENSE and README.

So, to summarize, I'm writing this mail to find out about the authorship
(can you
confirm it's yours?), and in case this is your code to see where you
stand regarding
Antti's concerns. I.e. what's the current license terms; are you ok with
relicensing; etc.


If the relevant code is going to be dual licensed, BSD/ISC as the 
alternative would be best.


Another option is to distribute the rump kernel part of the code in 
Hurd.  I think it's expected for code found in Hurd to be GPL, and since 
it's possible for GPL projects to incorporate BSD-licensed code without 
any adverse side effects or surprises for users, the whole licensing 
problem would go away.  (or did I miss something?)




Re: [PATCH] Rump on GNU/Hurd (4): Userspace PCI I/O

2015-08-16 Thread Robert Millan


Hi Zheng Da,

First of all, allow me to show you my appreciation for your effort on 
integrating
DDE with the Hurd. The groundwork on creating facilities that enable userspace
drivers has been greatly helpful on this little project of mine.

Just to put you in context, I've ported Rump (http://rumpkernel.org/) to 
GNU/Hurd
and written some extensions that allow it to run its own PCI drivers in 
userspace.

For that I used the same facilities in Gnu Mach that libddekit is using, and 
also
imported some the code in libddekit for userspace interrupt management. Olaf 
(see
below) believes that this code was written by you:

El 16/08/15 a les 21:02, Olaf Buddenhagen ha escrit:

On Sun, Aug 16, 2015 at 01:09:59PM +0200, Robert Millan wrote:


* It includes code from other people under GPLv2;



   - intrthread() is heavily based on intloop() from
   hurd/libddekit/interrupt.c


I haven't checked, but I assume this is form a Hurd-specific part of
DDE, which has been implemented by Zheng Da for the Hurd port
specifically? If so, we could try contacting him.


Is this correct?

I'm currently trying to merge the resulting code into Rump. This raises the
question on which license is the code in intloop() under. By lack of any other
statement one would have to assume it's GPLv2.

The Rump maintainer has some concern regarding licenses:

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. In 
any case if you
think it's an issue let me know and we'll try to find a solution:
- intrthread() is heavily based on intloop() from 
hurd/libddekit/interrupt.c
[...]

 I'm not worried about GPL, but I am worried about someone using GPL accidentally when 
they did not intend to.  It's better if the code can offered under LGLP, but not a 
requirement.  One option would be to put Hurd support under gpl/src-hurd.  Or 
just be very explicit about the licensing both in LICENSE and README.

So, to summarize, I'm writing this mail to find out about the authorship (can 
you
confirm it's yours?), and in case this is your code to see where you stand 
regarding
Antti's concerns. I.e. what's the current license terms; are you ok with 
relicensing; etc.

Please let us know about it!

Much appreciated,

--
Robert Millan