Hello,
Damien Zammit, le ven. 10 avril 2020 14:37:52 +1000, a ecrit:
> I can't contribute patches upstream to rump currently because netbsd
> are planning to merge buildrump.sh into netbsd src/ tree and the "upstream"
> rump repos will possibly be deprecated/merged into netbsd.
Oh!
> I believe
On 4/4/20 9:06 am, Samuel Thibault wrote:
> Well, rump does have it but doesn't install it (as well as dkio.h), but
> it should, shouldn't it? Otherwise rump_sys_ioctl is basically unusable
> without it. It looks like makekernelheaders could be installing this?
> Probably we don't want all of
Damien Zammit, le ven. 03 avril 2020 21:48:15 +1100, a ecrit:
> On 3/4/20 6:45 pm, Samuel Thibault wrote:
> > Isn't that ./buildrump.sh/src/sys/sys/ioccom.h ?
>
> Oh yea, I have added that one instead to our tree (rump doesn't have it).
Well, rump does have it but doesn't install it (as well as
Hi, see attached patch.
On 3/4/20 6:45 pm, Samuel Thibault wrote:
> I don't see the reason why for most of them: libpthread.a,
> libpciaccess.a, libdl.a are not _pic.a variants for instance.
>
> For a start, try to use non-pic variants for libtrivfs,
> libshouldbeinlibc, libports, libiohelp,
Damien Zammit, le ven. 03 avril 2020 12:23:56 +1100, a ecrit:
> On 3/4/20 9:28 am, Samuel Thibault wrote:
> > Concerning the link line, I don't understand why hardcoding everything?
> >
> > - For a start, are the _pic.a versions really needed? The .a versions
> > should just work.
>
> I think
On 3/4/20 9:28 am, Samuel Thibault wrote:
> Concerning the link line, I don't understand why hardcoding everything?
>
> - For a start, are the _pic.a versions really needed? The .a versions
> should just work.
I think the _pic.a versions are required. I could not get rump to work with .a
That
Damien Zammit, le lun. 30 mars 2020 22:22:12 +1100, a ecrit:
> I cleaned up rumpdisk and used your new api. See patch below.
I'm amazed how very straighforward this implementation looks, rump rocks
:)
Concerning the link line, I don't understand why hardcoding everything?
- For a start, are
Damien Zammit, le mer. 01 avril 2020 16:04:25 +1100, a ecrit:
> Thanks. See patch for configure.ac/Makefile changes to make rumpdisk
> optional.
AIUI you made it so that one has to pass --without-librump to disable
rump support? That is not how it is usually done. Usually configure.ac
would
Damien Zammit, le mer. 01 avril 2020 16:04:25 +1100, a ecrit:
> For some reason --without-librump still creates the Makefile for rumpdisk,
That's expected with autotools, they always generate files from .in
files.
Samuel
On 30/3/20 10:38 pm, Samuel Thibault wrote:
> Damien Zammit, le lun. 30 mars 2020 22:22:12 +1100, a ecrit:
>> I don't think block-rump.c needs a separate library, what do you think?
>
> Indeed, the way you did seems well-contained.
Thanks. See patch for configure.ac/Makefile changes to make
Damien Zammit, le lun. 30 mars 2020 22:22:12 +1100, a ecrit:
> I don't think block-rump.c needs a separate library, what do you think?
Indeed, the way you did seems well-contained.
Samuel
On 30/3/20 9:12 am, Samuel Thibault wrote:
> I cleaned that quite heavily, to have something that actually looks like
> a library :)
> Along the way I renamed various things, basically to add the machdev
> prefix, see machdev.h and machdev-device_emul.h
Fantastic! I cleaned up rumpdisk and used
Damien Zammit, le lun. 30 mars 2020 10:16:29 +1100, a ecrit:
> I don't know if I can do that, I committed an upstream branch,
> then merged it into master and added patches.
Ok.
Ah, there is a upstream/0_20191130 tag, I can build the orig tarball
from that.
Samuel
On 30/3/20 7:06 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> Then you'll need me to push latest rumpkernel tree so you can build rump libs
>
> Could you commit the upstream tarballs to the repo as well so I have the
> correct version? You can do it
Hello,
Damien Zammit, le dim. 29 mars 2020 23:19:28 +1100, a ecrit:
> >> - put the files common to dde-based and rump-based libmachdev to
> >> libmachdev/.
I cleaned that quite heavily, to have something that actually looks like
a library :)
Along the way I renamed various things, basically to
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> Then you'll need me to push latest rumpkernel tree so you can build rump libs
Could you commit the upstream tarballs to the repo as well so I have the
correct version? You can do it by running this inside the debian repo:
Damien Zammit, le dim. 29 mars 2020 23:19:28 +1100, a ecrit:
> I created a ds_pre_server() hook in libmachdev and implemented it for
> libmachdevdde,
> and left an empty stub for libmachdevrump.
I don't see why making it a hook:
+void ds_pre_server(void)
+{
+ /* empty */
+}
+
+int main()
+{
+
Damien Zammit, le dim. 29 mars 2020 23:19:28 +1100, a ecrit:
> On 29/3/20 4:16 pm, Damien Zammit wrote:
> > Hurd TODO for Damien:
> > =
> >
> > - Fix libstore patch
> Done
Applied, thanks!
Samuel
On 29/3/20 4:16 pm, Damien Zammit wrote:
> Hurd TODO for Damien:
> =
>
> - Fix libstore patch
Done
> - Remove useless debugging eg:
Done
>
> - Remove most of this header:
>>> +++ b/libmachdevrump/dev_hdr.h
>> - put the files common to dde-based and rump-based libmachdev to
Damien Zammit, le dim. 29 mars 2020 16:01:30 +1100, a ecrit:
> On 29/3/20 11:24 am, Samuel Thibault wrote:
> > Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> >> Apply these first to libpciaccess:
> >> upstreaming/libpciaccess/99-fix-pciconf-calls
> >>
Damien Zammit, le dim. 29 mars 2020 15:55:42 +1100, a ecrit:
> I fixed rump instead. It now unmaps pci devices correctly and I tested
> it without the above patch at all, it works.
Ok, that's better.
> > I don't really know why libpciaccess maintainers thought it should
> > exclude mapping the
Hurd TODO for Damien:
=
- Fix libstore patch
- Remove useless debugging eg:
>> + mach_print("device open\n");
- Remove most of this header:
>> +++ b/libmachdevrump/dev_hdr.h
- Complete the following:
> I see that most of the patch is actually coming from the
On 29/3/20 11:31 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> I could then push out my latest debian rumpkernel tree.
>
> I'd say yes, you can go ahead.
>
> I don't think you need to wait for libpciaccess patches? Sure all
> the pieces are needed
On 29/3/20 11:24 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> Apply these first to libpciaccess:
>> upstreaming/libpciaccess/99-fix-pciconf-calls
>> upstreaming/libpciaccess/99-region-probe
>> upstreaming/libpciaccess/99-common-reuse-mapping
>
>
Hi Samuel,
On 29/3/20 11:19 am, Samuel Thibault wrote:
> --- a/src/common_interface.c
> +++ b/src/common_interface.c
> @@ -290,11 +290,13 @@ pci_device_map_range(struct pci_device *dev, pciaddr_t
> base,
>
> /* Make sure that there isn't already a mapping with the same base and
> *
> diff --git a/libmachdevrump/block.c b/libmachdevrump/block.c
> new file mode 100644
> index 0..e4b519bb8
> --- /dev/null
> +++ b/libmachdevrump/block.c
> +static io_return_t
> +device_open (mach_port_t reply_port, mach_msg_type_name_t reply_port_type,
> + dev_mode_t mode, char
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> I could then push out my latest debian rumpkernel tree.
I'd say yes, you can go ahead.
I don't think you need to wait for libpciaccess patches? Sure all
the pieces are needed for the whole thing to work, but compile-wise,
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> I'm not sure how to solve this exactly, I'm guessing you don't want
> rumpkernel to be a build-dep for hurd.
I don't think this is a problem?
I mean, we have cross-deps in various places: we have to build hurd
before building glibc
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> Apply these first to libpciaccess:
> upstreaming/libpciaccess/99-fix-pciconf-calls
> upstreaming/libpciaccess/99-region-probe
> upstreaming/libpciaccess/99-common-reuse-mapping
Concerning 99-common-reuse-mapping, as mentioned I'd
diff --git a/src/hurd_pci.c b/src/hurd_pci.c
index 26505f3..ada7af8 100644
--- a/src/hurd_pci.c
+++ b/src/hurd_pci.c
@@ -162,7 +162,7 @@ pciclient_cfg_read(mach_port_t device_port, int reg, char
*buf,
data = buf;
nread = *nbytes;
-err = pci_conf_read(device_port, reg, , ,
--- a/src/common_interface.c
+++ b/src/common_interface.c
@@ -290,11 +290,13 @@ pci_device_map_range(struct pci_device *dev, pciaddr_t
base,
/* Make sure that there isn't already a mapping with the same base and
* size.
+ * If there is, use it.
*/
for (i = 0; i <
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> upstreaming/hurd/pciarbiter-short-rw.patch
Applied, thanks!
Samuel
Hello,
Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
> I am sending this primarily because I don't want to lose these patches.
Ok, I already have comments on them :)
+ /* Parse @master:/dev/hello */
+ master = strdup (name);
+ copy = strdup (name);
+ pos =
Hi Samuel,
I am sending this primarily because I don't want to lose these patches.
With the attached debian patches for libpciaccess and hurd,
the rumpkernel debian packages I have prepared locally work out of the box.
The problem is, you can't compile hurd with these patches without building
34 matches
Mail list logo
