Re: new hurd gnumach packages
Samuel Thibault, le Tue 07 Jul 2015 16:40:27 +0200, a écrit : This box keeps building installing packages, building a package, deinstalling packages. A way to reproduce this workload is using pbuilder instead of building in a system with dependencies already installed. Samuel
Re: Question with moving mount/umount logic in glibc
Justus Winter 4win...@informatik.uni-hamburg.de skribis: Sounds awesome. One thing to be aware of (iirc) is that the mount/umount code depends on the fstab parser. I'm not sure whether it is needed for the mount/umount(2) interface, or just for the command line frontend. I bet the former, that means that you also have to move the fstab parser to the libc. /etc/fstab handling is not part of the mount/umount functions (on Linux mount and umount are syscall wrappers generated from syscalls.list.) Ludo’.
Question with moving mount/umount logic in glibc
Hello everyone,
Time for glibc questions :)
I have a question about utils/mount.c. In the contribution page it says
Move the mount/umount logic from utils/{,u}mount.c into glibc.
After a short conversation with Thomas here 's how I think I will implement it :
(glibc)/sysdeps/mach/hurd/mount.h : Declarations of mount, umount,
umount2 and possible
flags as described in
http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html
and compared to [glibc]/sysdeps/unix/sysv/linux/sys/mount.h, so we can
stay compatibile at the API level
with other systems.
(glibc)/sysdeps/mach/hurd/mount.hc: Mount/umount implementation. In
other words move the
implementation from hurd to glibc.
(hurd)/utils/mount.c: A util which will use the glibc mount
implementation to do the same work as before.
And here are a few things I have to keep an eye on, which Thomas pointed out.
1) After the change, existing older Hurd binaries should still work
fine, and with the changed
[hurd]/utils/mount.c
2) The mount interface provided by glibc need to be just enough to
stay compatibile at the API level
which is what we want in Guix.
WDYT? Please feel free to comment/suggest. :-)
Manolis
Re: Question with moving mount/umount logic in glibc
Hi Manolis :)
Quoting Manolis Ragkousis (2015-07-07 16:04:30)
I have a question about utils/mount.c. In the contribution page it says
Move the mount/umount logic from utils/{,u}mount.c into glibc.
After a short conversation with Thomas here 's how I think I will implement
it :
(glibc)/sysdeps/mach/hurd/mount.h : Declarations of mount, umount,
umount2 and possible
flags as described in
http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html
and compared to [glibc]/sysdeps/unix/sysv/linux/sys/mount.h, so we can
stay compatibile at the API level
with other systems.
Yes. Compatibility is Hurds killer feature.
WDYT? Please feel free to comment/suggest. :-)
Sounds awesome. One thing to be aware of (iirc) is that the
mount/umount code depends on the fstab parser. I'm not sure whether
it is needed for the mount/umount(2) interface, or just for the
command line frontend. I bet the former, that means that you also
have to move the fstab parser to the libc.
Cheers,
Justus
Re: new hurd gnumach packages
Richard Braun, le Tue 07 Jul 2015 16:33:22 +0200, a écrit : This is scary. Justus and I never saw anything wrong in a month with regular builds of iceweasel/hurd/glibc packages, and you get two assertions in a few days... Actually I had another one, but with same unavailability of a backtrace as my previous report. This box keeps building installing packages, building a package, deinstalling packages. It looks like there is discrepancy between ipc/ipc_object.c:660 and kern/rdxtree.h:94. Can you manage to get -O0 traces ? I'll try that. Samuel
Re: new hurd gnumach packages
On Tue, Jul 07, 2015 at 12:33:50AM +0200, Samuel Thibault wrote: I got another hit, I have attached the screenshot, and here are the addrlines: This is scary. Justus and I never saw anything wrong in a month with regular builds of iceweasel/hurd/glibc packages, and you get two assertions in a few days... /usr/src/gnumach/build-dbg/../kern/debug.c:97 /usr/src/gnumach/build-dbg/../kern/debug.c:66 /usr/src/gnumach/build-dbg/../kern/rdxtree.c:233 /usr/src/gnumach/build-dbg/../kern/rdxtree.h:94 /usr/src/gnumach/build-dbg/../ipc/ipc_object.c:660 /usr/src/gnumach/build-dbg/../ipc/ipc_kmsg.c:2300 /usr/src/gnumach/build-dbg/../ipc/ipc_kmsg.c:2408 /usr/src/gnumach/build-dbg/../ipc/ipc_kmsg.c:2512 /usr/src/gnumach/build-dbg/../ipc/mach_msg.c:1466 It looks like there is discrepancy between ipc/ipc_object.c:660 and kern/rdxtree.h:94. Can you manage to get -O0 traces ? -- Richard Braun
Re: new hurd gnumach packages
On Tue, Jul 07, 2015 at 04:40:27PM +0200, Samuel Thibault wrote: It looks like there is discrepancy between ipc/ipc_object.c:660 and kern/rdxtree.h:94. Can you manage to get -O0 traces ? I'll try that. Even with a clean trace, I have a hard time understanding how it could happen. I think the best thing we can do is get the value of node-entries[index] at the time of the assertion. If it's not NULL, the node obtained from the insertion loop should normally be non-NULL too, making the function return ERR_BUSY. But entries use the least significant bit in entry slots. The node variable (in the common insertion functions) is actually rdxtree_entry_addr(prev-entries[index]), which masks the LSB. So I guess node is actually NULL, meaning the entry should be 1. As documented above struct rdxtree_node : This implementation assumes that all nodes and stored pointers are at least 4-byte aligned, and uses the least significant bit of entries to indicate the pointer type. This bit is set for internal nodes, and clear for stored pointers so that they can be accessed from slots without conversion. Insertion functions do check that stored pointers aren't NULL and are correctly aligned. Clearing an entry (rdxtree_node_remove) does set an entry to NULL, so the LSB should get back to 0 in all cases. I really don't see how an entry could be 1... -- Richard Braun
