[PATCH] lwip: Allocate the loopback netif by default

From: Joan Lledó The translator received a null `netif_list` during initialization, this caused a few bugs. When started without parameters, the translator didn't add any new interface to `netif_list`, and that broke any subsequent fsysopts over the translator, as the stack was being

lwip: Allocate the loopback netif by default

Hi, This patch fixes a few bugs. The translator was assuming one interface was already allocated in `netif_list` when calling `init_ifs` during startup, and used it to configure the loopback interface [1]. That was possibly true in the past but after upgrading liblwip I found `netif_list` is

Re: dhcpcd: FTBFS on Hurd

Hi Martin-Éric, you can write me for help when you need it. Regards On 24/11/23 6:50, Martin-Éric Racine wrote: Greetings, As dhcpcd is slated to replace dhclient as the default DHCP client in Debian, I've been trying to fix the build on Hurd, which is the only architecture that has

Re: [PATCH v3 hurd] pci: Add RPCs for taking and freeing io ports by region

Hi, Thank you Damien and Samuel for your explanations. On 22/7/23 3:31, Damien Zammit wrote: diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c index 4bb5c97a..6b3d6918 100644 --- a/pci-arbiter/netfs_impl.c +++ b/pci-arbiter/netfs_impl.c @@ -522,6 +522,14 @@ netfs_attempt_read

Re: [PATCH v2 hurd] pci: Add RPCs for taking and freeing io ports by BAR

Hi Damien, I think your design is not compatible with nested arbiters. Correct me if I'm wrong, but AFAIK the arbiter doesn't know if it's a main or a nested arbiter, it's libpciaccess who handles that. So the arbiter code must be the same and work no matter if it's main or nested. In your

pci-arbiter: Prevent mapping IO region files

Hello, Time ago I sent some patches to implement mapping region and ROM files using mmap(). However, a BAR region can represent either memory or I/O space, and only the former should be allowed to be mapped, since I/O BARs don't contain physical memory addresses, but I/O addresses. I attached a

[PATCH] pci-arbiter: Prevent mapping IO regions

From: Joan Lledó * pci-arbiter/netfs_impl.c: * get_filemap_region(): Return MACH_PORT_NULL and set errno to EOPNOTSUPP when the client tries to map a IO region file. --- pci-arbiter/netfs_impl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter

Re: Xorg news

Hi, El 23/8/22 a les 19:30, Samuel Thibault ha escrit: And also, I have just uploaded version 0.16-3+hurd.of libpciaccess. The issue was that the map_legacy method was completely broken. What was the problem with it? Ideally it'd be able to use the map_region method, Do you mean

Re: [PATCH libpciaccess] hurd: Clients or nested arbiters don't touch ioports

Hi, El 23/8/22 a les 10:36, Damien Zammit ha escrit: @@ -600,14 +599,14 @@ static const struct pci_system_methods hurd_pci_methods = { .read = pci_device_hurd_read, .write = pci_device_hurd_write, .fill_capabilities = pci_fill_capabilities_generic, -.open_legacy_io =

Re: pci-arbiter: Implement mapping for ROM files

Hi, El 16/8/22 a les 18:10, Samuel Thibault ha escrit: ? Any memory allocated by a process will be freed when the process shuts down. Yes, I know, just wondering if there was a good practice about malloc/free in the Hurd.

Re: pci-arbiter: Implement mapping for ROM files

Hi, I just though... shouldn't this allocated memory be freed somewhere when the arbiter shuts down? El 15/8/22 a les 20:33, Samuel Thibault ha escrit: Samuel Thibault, le lun. 15 août 2022 20:20:16 +0200, a ecrit: Joan Lledó, le lun. 15 août 2022 20:07:09 +0200, a ecrit: El 15/8/22 a les

Re: pci-arbiter: Implement mapping for ROM files

Hi, El 15/8/22 a les 20:20, Samuel Thibault ha escrit: Sorry, I meant: why can't we do that for ROMs? Does libpciaccess not provide a way to map ROMs? That's the problem: it doesn't. It only provides the function pci_device_read_rom() which copies the entire ROM to a given pointer. But it

Re: pci-arbiter: Implement mapping for ROM files

Hi, El 15/8/22 a les 19:37, Samuel Thibault ha escrit: Mmm, but doesn't libpciaccess allow to map the BAR?Then pci-arbiter could create a read-only memory proxy of the mapping? Yes, the arbiter exposes the BAR regions as files called "region0", "region1", etc. And they can be mapped through

[PATCH] Implement mapping for ROM files

From: Joan Lledó * pci-arbiter/device_map.h: * pci-arbiter/device_map.c: * New function: device_map_rom * Copies the whole rom in the arbiter space. * pci-arbiter/pcifs.h: * struct pcifs_dirent: * New field to store the mapping address for each device rom. o pci-arbiter/func_files.h

pci-arbiter: Implement mapping for ROM files

Helllo Hurd, I wrote a patch to allow mapping ROM files from the arbiter file system. In order to achieve this, the arbiter first allocates and copies the entire device ROM in its space the first time it's accessed, and returns a proxy to that memory region when a client requests a ROM

[SCM] GNU Mach branch, master, updated. v1.8-359-g0e53658a

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU Mach". The branch, master has been updated via 0e53658a0c0444a28d7a1858b311d811b9018f60 (commit) from

Re: gnumach: bug in dev_pager.c

Since it was a tiny patch I pushed the changes myself. El 8/8/22 a les 2:16, Samuel Thibault ha escrit: It seems to me that the correct condition at lines 238 and 316 should be: if (!queue_end(bucket, >links)) That should be it indeed!

gnumach: bug in dev_pager.c

Hi, I think there's a bug in dev_pager.c, at methods dev_pager_hash_delete() and dev_device_hash_delete(), lines 238 and 316: https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/device/dev_pager.c#n238 https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/device/dev_pager.c#n316 It's

Bug#1014447: bullseye-pu: package lwip/2.1.2+dfsg1-8

:52.0 +0200 @@ -1,3 +1,10 @@ +lwip (2.1.2+dfsg1-8+deb11u1) bullseye; urgency=high + + * Fix CVE-2020-22283 + * Fix CVE-2020-22284 + + -- Joan Lledó Wed, 06 Jul 2022 10:55:52 +0200 + lwip (2.1.2+dfsg1-8) unstable; urgency=medium * No-change source-only upload to allow testing

[PATCH] Hurd: Fix initialization order

From: Joan Lledó --- src/hurd_pci.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/src/hurd_pci.c b/src/hurd_pci.c index 70a9f89..653faa5 100644 --- a/src/hurd_pci.c +++ b/src/hurd_pci.c @@ -610,7 +610,8 @@ pci_system_hurd_create(void) { int

Re: [PATCH] hurd: Implement device memory mapping

El 12/3/22 a les 12:30, Samuel Thibault ha escrit: > Is netdde using your modified libpciaccess? That was it, netdde was using the original libpciaccess. I'm attaching a patch to fix the problem.

Re: [PATCH] hurd: Implement device memory mapping

El 23/1/22 a les 18:44, Samuel Thibault ha escrit: With a normal hurd system, i.e. no bootstrap pci-arbiter, and using netdde, which is thus supposed to eventually use the translator sitting on /servers/bus/pci I still don't know how to reproduce this, if I run a normal Hurd with an e1000

Re: Recent libpciaccess changes

Hi, El 7/2/22 a les 11:42, Damien Zammit ha escrit: libpciaccess: I have not been able to prove it yet, but I think the function call pci_device_hurd_map_range() attempts to look up _SERVERS_BUS_PCI during bootstrap and fails because it does not exist (no root filesystem exists). Yes, the

Re: [PATCH] hurd: Implement device memory mapping

Hi, El 9/1/22 a les 1:02, Samuel Thibault ha escrit: Err, this is breaking everything when pci-arbiter is not running as a bootstrap translator. In that case e.g. netdde succeeds getting the privileged port, and thus tries to open pci, but fails, and thus the whole thing aborts. What problem

Re: [PATCH] hurd: Implement device memory mapping

El 9/1/22 a les 1:15, Samuel Thibault ha escrit: Err, this is breaking everything when pci-arbiter is not running as a bootstrap translator. In that case e.g. netdde succeeds getting the privileged port, and thus tries to open pci, but fails, and thus the whole thing aborts. What problem the

Re: [PATCH] pci-arbiter: Stop using deprecated region memory pointer

I updated the comment

[PATCH] pci-arbiter: Stop using deprecated region memory pointer

From: Joan Lledó Use a internal array of pointers instead * pci-arbiter/device_map.h: * Update device_map_region() prototype * Now it receives an output address as parameter * pci-arbiter/device_map.c: * Update device_map_region() definition to match the new prototype * Support

[PATCH] pci-arbiter: Stop using deprecated region memory pointer

From: Joan Lledó Use a internal array of pointers instead * pci-arbiter/device_map.h: * Update device_map_region() prototype * Now it receives an output address as parameter * pci-arbiter/device_map.c: * Update device_map_region() definition to match the new prototype * Support

Re: [PATCH] pci-arbiter: Stop using deprecated region memory pointer

Hi, > Rather >= ? No, libpciaccess accepts using the legacy method for addrress up to 0x10 included. > Also, why this address? Putting a comment there would be welcome to explain > the magic number. I'm taking the condition from here:

[PATCH] hurd: Implement device memory mapping

From: Joan Lledó * src/hurd_pci.c: * Implement device memory mapping functions * pci_device_hurd_map_range * pci_device_hurd_unmap_range * pci_device_hurd_map_legacy * pci_device_hurd_unmap_legacy * src/x86_pci.h

Re: [PATCH] hurd: Implement device memory mapping

Hi, > This is not using map.base as set by pci_device_hurd_map_legacy? You're right, I checked it out and found that libpciaccess has a set of old and deprecated memory mapping functions to map/unmap entire BARs (regions). Later, they added new functions to allow manny mappings in the same

[PATCH] pci-arbiter: Stop using deprecated region memory pointer

From: Joan Lledó Use a internal array of pointers instead * pci-arbiter/device_map.h: * Update device_map_region() prototype * Now it receives an output address as parameter * pci-arbiter/device_map.c: * Update device_map_region() definition to match the new prototype * Support

Re: [PATCH] hurd: Implement device memory mapping

Hi, I attached a patch with the changes

[PATCH] hurd: Implement device memory mapping

From: Joan Lledó * src/hurd_pci.c: * Implement device memory mapping functions * pci_device_hurd_map_range * pci_device_hurd_unmap_range * pci_device_hurd_map_legacy * pci_device_hurd_unmap_legacy * src/x86_pci.h

Re: [PATCH] hurd: Implement device memory mapping

Hi, El 28/12/21 a les 13:55, Samuel Thibault ha escrit: ? The interface explicitly says they can be different. Samuel Sorry, I was confused. I meant the function pci_device_hurd_map_range at libpciaccess. If io_map returns different ports for robj and wobj, we can only assign one of them

Re: [PATCH] hurd: Implement device memory mapping

Hi, El 19/12/21 a les 16:40, Samuel Thibault ha escrit: “ For objects where read data and write data are the same, these objects will be equal, otherwise they will be disjoint. ” In that case, which one should we return as pager? Probably the right thing is to return an error, since a

[PATCH 1/3] libnetfs: new user callback: netfs_get_filemap()

From: Joan Lledó Provide the user with a new callback so they can implement file mapping over file system nodes. * libnetfs/netfs.h: Add prototype for netfs_get_filemap * libnetfs/file-map.c: netfs_get_filemap definition * libnetfs/Makefile: add file-map.c to sources --- libnetfs/Makefile

Re: [PATCH 1/3] libnetfs: new user callback: netfs_get_filemap()

> This only provides the declaration. Sorry, I hope it's correct now

[PATCH 2/3] libnetfs: Implement RPC: io_map

From: Marcus Brinkmann * libnetfs/iostubs.c: implement io_map --- libnetfs/iostubs.c | 46 +++--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/libnetfs/iostubs.c b/libnetfs/iostubs.c index a5ff4504..df48f8b7 100644 ---

[PATCH 3/3] pci-arbiter: Implement memory mapping over region files

From: Joan Lledó * pci-arbiter/Makefile: * Add device_map.c to sources * pci-arbiter/device_map.c: * pci-arbiter/device_map.h: * New module for device mapping * Relies on libpciaccess mapping methods * pci-arbiter/func_files.c: * io_region_file(): Use the new

[PATCH 1/3] libnetfs: new user callback: netfs_get_filemap()

From: Joan Lledó Provide the user with a new callback so they can implement file mapping over file system nodes. * libnetfs/netfs.h: Add prototype for netfs_get_filemap --- libnetfs/netfs.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libnetfs/netfs.h b/libnetfs/netfs.h index

Re: [PATCH 1/3] libnetfs: new user callback: netfs_get_filemap()

> Rather than requiring the translator to provide a netfs_get_filemap > (which breaks compatibility for any existing translator using > libnetfs), you can add a weak definition in libnetfs, see for instance > libnetfs/set-get-trans.c. Like this? I'm also attaching the other two patches, since

Re: [PATCH] hurd: Implement device memory mapping

El 12/12/21 a les 16:19, Samuel Thibault ha escrit: Don't we need else { pager = wobj; } ? Otherwise pager would be undefined. In the case when the two previous conditions are false, what about robj? can we be sure it's null and not leaked? When could the two previous conditions be

[PATCH 3/3] pci-arbiter: Implement memory mapping over region files

From: Joan Lledó * pci-arbiter/Makefile: * Add device_map.c to sources * pci-arbiter/device_map.c: * pci-arbiter/device_map.h: * New module for device mapping * Relies on libpciaccess mapping methods * pci-arbiter/func_files.c: * io_region_file(): Use the new

Re: PCI arbiter memory mapping

Hi, These patches implement device memory mapping in the arbiter by using the new gnumach RPC

[PATCH 2/3] libnetfs: Implement RPC: io_map

From: Marcus Brinkmann * libnetfs/iostubs.c: implement io_map --- libnetfs/iostubs.c | 46 +++--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/libnetfs/iostubs.c b/libnetfs/iostubs.c index a5ff4504..df48f8b7 100644 ---

Re: About consuming/releaseing ports in libpciaccess

Hi, > These rules are different between the server and client sides of MIG. > I was talking about the server side; but you are on the client side > here. On the client side, whether or not the call consumes a port > right is determined by the "disposition" specified in .defs (or > specified at

[PATCH] hurd: Implement device memory mapping

From: Joan Lledó * src/hurd_pci.c: * Implement device memory mapping functions * pci_device_hurd_map_range * pci_device_hurd_unmap_range * pci_device_hurd_map_legacy * pci_device_hurd_unmap_legacy * src/x86_pci.h

About consuming/releaseing ports in libpciaccess

Hi, I'm trying to implement a correct release of resources in libpciaccess x86 module. I have this text from Sergey as reference: > Consuming, as in taking ownership of, or "eating" the passed-in reference. > > If a call consuming something, the callee takes ownership of the > passed-in

Re: [PATCH] new interface: memory_object_get_proxy

Hi, I tested it and everything works fine. I'm attaching the two patches for convenience. About the name, feel free to change it if you want, although I think if we rename it then the function should be moved to vm_map.c, maybe just below vm_region()

[PATCH 1/2] new interface: memory_object_get_proxy

From: Joan Lledó To get a proxy to the region a given address belongs to, with protection and range limited to the region ones. * include/mach/mach4.defs: memory_object_get_proxy RPC declaration * vm/memory_object_proxy.c: memory_object_get_proxy implementation --- include/mach/mach4.defs

[PATCH 2/2] Memory proxies: Add support for anonymous mappings

From: Sergey Bugaev * vm/memory_object_proxy.c: * memory_object_get_proxy(): * Return KERN_INVALID_ARGUMENT when the entry is a submap. * Create a pager for the vm_object when the entry doesn't have any yet, since it's an anonymous mapping. --- vm/memory_object_proxy.c | 21

Re: [VULN 0/4] Hurd vulnerability details

Hi, El 2/11/21 a les 17:35, Samuel Thibault ha escrit: Hello, Thanks a lot for this writing! That'll surely be an interesting read for whoever wants to look a bit at the details of how the Hurd works. And of course thanks for finding and fixing the vulnerabilities :) Yes, I'm gonna read it

Re: [PATCH] new interface: memory_object_get_proxy

Hi, El 1/11/21 a les 17:47, Sergey Bugaev ha escrit: With this diff (on top of your patch), it finally works sanely for me: Cool, great work. I'd like to try it myself but I won't have the time until next weekend. I'll merge your changes with mine and make my tests.

Re: [PATCH] new interface: memory_object_get_proxy

Hi, El 1/11/21 a les 14:36, Sergey Bugaev ha escrit: * "Anonymous" mappings (created with a null memory object) If they provide no object when calling vm_map, then the kernel uses the default pager, isn't it? Can't you send a reference to the default pager to memory_object_create_proxy()?

[PATCH] new interface: memory_object_get_proxy

From: Joan Lledó To get a proxy to the region a given address belongs to, with protection and range limited to the region ones. * include/mach/mach4.defs: memory_object_get_proxy RPC declaration * vm/memory_object_proxy.c: memory_object_get_proxy implementation --- include/mach/mach4.defs

Re: [PATCH] new interface: memory_object_get_proxy

Here you go

Re: [PATCH] new interface: memory_object_get_proxy

Hi, El 30/10/21 a les 14:06, Sergey Bugaev ha escrit: > I hope this makes sense; I'd be happy to expand if not. Thanks for your explanations, it makes sense but there's still one thing I don't understand: if memory_object_create_proxy() is the owner of the pager it receives as parameter, and

[PATCH] new interface: memory_object_get_proxy

From: Joan Lledó To get a proxy to the region a given address belongs to, with protection and range limited to the region ones. * include/mach/mach4.defs: memory_object_get_proxy RPC declaration * vm/memory_object_proxy.c: memory_object_get_proxy implementation --- include/mach/mach4.defs

Re: [PATCH] new interface: memory_object_get_proxy

Hi, El 24/10/21 a les 19:50, Sergey Bugaev ha escrit: Naming: perhaps memory_object_create_vm_proxy ()? or even memory_object_create_task_vm_proxy ()? I don't care about the name, you guys decide. I would expect the request port argument to be a vm_task_t (i.e. a vm_map), not a full task.

[PATCH] new interface: memory_object_get_proxy

From: Joan Lledó To get a proxy to the region a given address belongs to, with protection and range limited to the region ones. * include/mach/mach4.defs: memory_object_get_proxy RPC declaration * vm/memory_object_proxy.c: memory_object_get_proxy implementation --- include/mach/mach4.defs

Re: gnumach RPC: get info about the calling task

Hi, I wrote a patch with the RPC as you guys asked. Please tell me if it fits your plans for mremap()

Re: gnumach RPC: get info about the calling task

El 17/10/21 a les 18:32, Samuel Thibault ha escrit> It will be useful to implement mremap with the same call. In your case you know the size, don't you? Yes That's almost the same, isn't it? (there is just the max_prot parameter, which you can indeed add to the RPC above). It's similar

Re: gnumach RPC: get info about the calling task

Hi, El 16/10/21 a les 13:27, Sergey Bugaev ha escrit: routine vm_make_proxy ( target_task : vm_task_t; address : vm_address_t; size : vm_size_t; out proxy : memory_object_t); Why the "size" parameter? I'd rather see a new wrapper for memory_object_create_proxy() which

Re: gnumach RPC: get info about the calling task

OK, I'll try with your design El 16/10/21 a les 18:06, Sergey Bugaev ha escrit: On Sat, Oct 16, 2021 at 6:54 PM Samuel Thibault wrote: Indeed, since it's the region that remembers which protection was allowed, we need a proxy there to enforce them. Right, that's also a good point.

[PATCH] new interface: vm_pager

From: Joan Lledó Given a task and an address, it returns the pager used to map that address in that task. * include/mach/mach4.defs: new interface declaration: vm_pager * vm/memory_object_proxy.h: add declaration for proxy hash functions * vm/memory_object_proxy.c: implement proxy hash

Re: gnumach RPC: get info about the calling task

El 12/10/21 a les 20:32, Samuel Thibault ha escrit: > Sergey Bugaev, le mar. 12 oct. 2021 16:22:48 +0300, a ecrit: >> So in the case of vm_map-backed pager, it should matter whether you >> have a task port to the target task, not whether you *are* the target >> task. If someone has a task port to

gnumach RPC: get info about the calling task

Hi, I'm working on the gnumach rpc to return a pager from a task and an address mapped in that task. For security reasons I'd like to check if the calling task is the same as the one the given map belongs to. But I don't know how to do it. In the rpc implementation, the function receives a

Re: Wrong MIG generated headers

Hi, El 11/9/21 a les 13:39, Sergey Bugaev ha escrit: This is a little change that Samuel has committed recently Thanks a lot, I was spending a lot of time on this. Should have asked before.

Wrong MIG generated headers

Hi, I'm having a weird issue trying to add a new interface to gnumach. I'm using this mach4.defs: -- /* * Mach Operating System * Copyright (c) 1994,1993,1992 Carnegie Mellon University * All Rights Reserved. * * Permission to use, copy,

[PATCH 2/2] dev_pager: rename hash macros

From: Joan Lledó Remove the reference to the pager hash since they are used both in the pager and the device hashes. * device/dev_pager.c: * Rename DEV_PAGER_HASH_COUNT to DEV_HASH_COUNT * Rename dev_pager_hash to dev_hash --- device/dev_pager.c | 26

Re: [PATCH] - gnumach: Implement offset in device map

Hi, > all elements that have the same hash key end up in the same list Ok, I missed that and the rest of the patch is wrong b/c of this. I did what you said and created a second hash table indexed by device + offset, leaving all code for dev_pager_hashtable untouched. I tried to insert the

[PATCH 1/2] dev_pager: implement offset

From: Joan Lledó * device/dev_pager.c: * struct dev_pager: add offset field * new struct dev_device_entry: includes device and offset * new hash table dev_device_hashtable * index [device + offset] * new functions dev_device_hash[init,insert,delete

[PATCH] dev_pager: Implement offset

From: Joan Lledó * New structure for the internal hash table: * 127 slots identified by the device address, each one containing a queue of pagers belonging to that device. * New auxiliary index [pager: device] to quick search of pagers

[PATCH] - gnumach: Implement offset in device map

Hi, I made the changed in the device mapper to implement the offset, also updated my branches of hurd and libpciaccess accordingly. It wasn't as trivial as it seemed, there were some /* HACK */ lines which in fact limited the number of pagers per device to 1, so once the system got a pager

Re: PCI arbiter memory mapping

El 18/8/21 a les 0:02, Sergey Bugaev ha escrit: To me it sounds like libpciaccess should have a Hurd-specific API addition that would let the user get the memory object That's a solution and can be done. But I'd like to know more about vm_region first. It seems it can return the object,

Re: PCI arbiter memory mapping

El 18/8/21 a les 0:13, Sergey Bugaev ha escrit: you can no longer get the underlying memory object with vm_region () How so? reading the docs I understood it does: https://www.gnu.org/software/hurd/gnumach-doc/Memory-Attributes.html "The port object_name identifies the memory object

Re: PCI arbiter memory mapping

Hi, I'm sorry I can't follow your discussion, I only know about the small part of the kernel I worked on. El 16/8/21 a les 23:07, Sergey Bugaev ha escrit: I don't think I understand enough about the situation. It would help if you or Joan were to kindly give me some more context :)

Re: PCI arbiter memory mapping

Hi, El 16/8/21 a les 20:16, Samuel Thibault ha escrit: Ok but I meant that the device_map interface already has has an "offset" Ok, now I got it, yes I think that's better. I'll do that. Actually I'm thinking that this is just another case of mremap(). I need help on this part, why is

Re: PCI arbiter memory mapping

Hi, El 5/8/21 a les 1:26, Samuel Thibault ha escrit: Is it not possible to avoid having to call memory_object_proxy_valid? maybe better fix device_map into supporting non-zero offset, I think it'd be a better solution to move the call to memory_object_proxy_valid() and the start value

Re: PCI arbiter memory mapping

Hi El 9/8/21 a les 19:45, Samuel Thibault ha escrit: I pushed the start/len start, along with a fix for the length. Could you proofread that part? I ran it and works fine

Re: Regarding copyright assignment to FSF

El 14/8/21 a les 23:26, Svante Signell ha escrit: How to make lwip by default enabled instead of pfinet? settrans -fgap /servers/socket/2 /hurd/lwip -6 /servers/socket/26

Re: PCI arbiter memory mapping

hi El 9/8/21 a les 19:45, Samuel Thibault ha escrit: I pushed the start/len start, along with a fix for the length. Could you proofread that part? It seems all right for me. I'll test this and check you other comments next weekend or the following.

Re: PCI arbiter memory mapping

Any thoughts on this? El 19/6/21 a les 11:50, Joan Lledó ha escrit: Hi Hurd, I finally got memory mapping working in the pci arbiter. That means any user with the proper permissions can map the device region files generated by an arbiter. This is also working for nested arbiters

Re: PCI arbiter memory mapping

Hi, El 20/6/21 a les 3:25, Damien Zammit ha escrit: Hi Joan, On 19/6/21 7:50 pm, Joan Lledó wrote: How does that interact with existing pci access for example, I think the AHCI rump driver works with DMA so do we need to also adjust the pci-userspace part of rumpkernel? I couldn't say

PCI arbiter memory mapping

Hi Hurd, I finally got memory mapping working in the pci arbiter. That means any user with the proper permissions can map the device region files generated by an arbiter. This is also working for nested arbiters. For this I made changes in libpciaccess, gnumach, and the Hurd: pci-arbiter

Re: Adding a new syscall to gnumach

Hi El 6/6/21 a les 14:48, Samuel Thibault ha escrit: AIUI it's not a system call that you are talking about, but an RPC. yes, you're right but it's not enough. What do you mean by "it's not enough"? What does not work *exactly*? sorry, gnumach compilation fails with this error: if

Adding a new syscall to gnumach

Hi Hurd, In my work to extend the memory proxies implementation, I'm considering adding a new syscall which receives a memory object and returns whether is it a proxy or not. I need something like that from the arbiter to properly set ranges when creating a new proxy. What are the steps to

Re: Privileged ports to access the arbiter

El 5/5/21 a les 20:22, Samuel Thibault ha escrit: Mmm, no, we only need it for the device_open case. We don't need it for falling back on using file_name_lookup (_SERVERS_BUS_PCI) And do we need write permissions to perform the scan?

Privileged ports to access the arbiter

Hi, fortunately, after pulling last changes and updating hurd-libs0.3 I solved my problems with the arbiter being killed. Now I got my user clients getting the maps correctly, and wanted to go further and implement memory object proxy nesting and pci-arbiter nesting. I found a problem

Re: pci arbiter being killed

El 17/4/21 a les 12:44, Damien Zammit ha escrit: Can you try rebasing on master and see if you have the same issues? After merging the last changes the arbiter hangs at startup, so it doesn't live enough to be killed. I think it's probably another effect of the same bug in my version of

Re: pci arbiter being killed

El 17/4/21 a les 14:14, Samuel Thibault ha escrit: Do you mean that without your changes there is no pci arbiter kill? Yes

Re: pci arbiter being killed

Hi, El 7/3/21 a les 20:33, Samuel Thibault ha escrit: You could e.g. put mach_prints in glibc's sysdeps/mach/hurd/kill.c's SIGKILL case. Possibly better also add a mach_print in hurd/hurdsig.c SIGKILL on _hurd_orphaned. I tried but I saw nothing, is it supposed to show the messages in the

Re: pci arbiter being killed

Hi El 7/3/21 a les 20:33, Samuel Thibault ha escrit: Joan Lledó, le dim. 07 mars 2021 20:08:21 +0100, a ecrit: is not there any process that kills the arbiter after a while of not being used? That shouldn't be happening. and how could I know who is sending the SIGKILL? How do you notice

pci arbiter being killed

Hi Hurd, I've observed how my instance of the pci arbiter receives a SIGKILL about a minute after start, it could be my fault as I've being messing around with gnumach, libpciaccess and the arbiter itself, but just to confirm: is not there any process that kills the arbiter after a while of

Re: Algú vol col·laborar en aquest projecte?

El 18 de gener de 2021 16:36:35 CET, "Ernest Adrogué" ha escrit: >Doncs a mi m'ha semblat una resposta molt adequada i respectuosa. A mi sí que m'ha semblat agressiva, si jo haguera rebut una resposta així quan vaig començar a programar potser ho hauria deixat. -- Enviat des d'/e/ Mail.

Re: Debugging gnumach

Hi, El 25/12/20 a les 23:43, Almudena Garcia ha escrit: My script is here https://gist.github.com/AlmuHS/73bae6dadf19b0482a34eaab567bfdfa Thanks. This didn't worked for me. Question: what's the content of hurd_qemu/hurd.img?

Debugging gnumach

Hi Hurd, recently I tried to implement ranges on memory object proxies[1]. I never worked on gnumach before, so as expected it failed. That's ok, but now I'd like to debug gnumach in order to find the issue. The docs[2] say I can either use the built-in debugger or gdb over qemu. I tried

Re: Contributing - available projects?

Hi, El 15/12/20 a les 21:40, Edward Haigh ha escrit: Of course! I'll set a dev environment up and do a little research on existing frameworks, then come back to you. I remember I used to use the Perl test suite to test the lwip translator, you may want to take a look.

Re: Implement paging on the pci arbiter

Hi, El 3/11/20 a les 23:13, Samuel Thibault ha escrit: > > That would probably work, yes. > > I got something pushed to my branch at [1]. But I found the implementation for pager proxies in gnu mach is incomplete. In particular I can't restrict a range to be mapped. I think I could fix it but

  1   2   3   4   5   6   >