Re: [PATCH]: gnumach - simplify interrupt handling

Samuel Thibault writes: > A simpler way for now would be to make deliver_intr and > device_intr_enable count how many "disables" we have for each irq. > Both device_intr_register and deliver_intr would increase it (and thus > disable the irq), and userland would have to call device_intr_enable >

Re: Reverting "libdiskfs: Shutdown pagers on startup_dosync."

Samuel Thibault <samuel.thiba...@gnu.org> writes: > Justus Winter, on mer. 17 janv. 2018 11:36:00 +0100, wrote: >> I'm still convinced that shutting down the servers is the right thing to >> do. The alternative is that the filesystem goes away with an unclean >> disk

Re: Reverting "libdiskfs: Shutdown pagers on startup_dosync."

Samuel Thibault writes: > Hello Justus, > > I had to revert your commit: Yes, I saw that :/ > “ > commit f05b6bae5cbdf3c221eba05987dea7ab14e6524f > Author: Samuel Thibault > Date: Mon Jan 15 22:00:11 2018 +0100 > > Revert

Re: [PATCH] PCI Arbiter

Joan Lledó writes: >>> +INTR_INTERFACE >> >> Leftover here. >> > > I cannot compile the server if I remove the `INTR_INTERFACE', The > mig-generated header doesn't mach my prototype. Is that what's left > over? Oh, I was wrong here. INTR_INTERFACE indeed only says

Re: [PATCH] PCI Arbiter

Hi Joan :) let me be the first to say: Awesome :) Joan Lledó writes: > Attached are two patches. The first one is to be applied to the Hurd > source tree and contains a new mig pci interface, the pci server and a > new library which includes the mig client stubs. So

Re: [PATCH] eth-multiplxer: Implement ds_device_close()

Hi :) "Joan Lledó" writes: > Hello, > > One difference between pfinet and lwip translators is that pfinet doesn't > delete interfaces (or I haven't found how to do it) while lwip does. For > instance, if one starts pfinet with: > > settrans -fga /servers/socket/2

Re: [PATCH hurd] fixup use lwip_{CFLAGS,LIBS}

Justus Winter <jus...@gnupg.org> writes: > --- > lwip/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lwip/Makefile b/lwip/Makefile > index e9289b5ae..8d4f45549 100644 > --- a/lwip/Makefile > +++ b/lwip/Mak

[PATCH hurd] fixup use lwip_{CFLAGS,LIBS}

--- lwip/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lwip/Makefile b/lwip/Makefile index e9289b5ae..8d4f45549 100644 --- a/lwip/Makefile +++ b/lwip/Makefile @@ -28,7 +28,7 @@ OBJS = $(patsubst %.S,%.o,$(patsubst %.c,%.o,\

Re: libpager

"Brent W. Baccala" writes: >> Are you aware of the pager rework in [0]? I'm considering to review and >> merge these changes. It may make sense to try to come up with a common >> API. What is the state of your library, is it a drop-in replacement? >> >> 0:

Re: [GSoC 2017] Point-to-point

Joan Lledó writes: > The last item in my initial TODO list was implementing the --peer > option available in pfinet. This week I've been working on it and it's > now done, so I can say the LwIP translator is now able to replace > pfinet. And indeed, I'm using lwip on

Re: libpager

"Brent W. Baccala" writes: > Hi - > > I've learned some interesting things about libpager that I'd like to share > with the list. Cool :) > I've found two bugs in the existing code that were "fixed" by the new > demuxer that sequentially services requests on each pager

Re: PulseAudio support

David Michael writes: > Hi, > > I just pushed an update to my Hurd distro build scripts for Fedora 26 > at https://github.com/dm0-/gnuxc which also includes a translator for > /dev/audio. I've uploaded the translator source separately if anyone > else is interested: > >

Re: Filtering Ethernet multicasr frames

Joan Lledó writes: > Hello, > > finally I've managed to fix the problem with IPv6 in my LwIP > translator, and the problem was that the driver was discarding some > Ethernet multicast frames. > > I've fixed it by enabling the IFF_ALLMULTI flag through >

Re: [GSoC 2017] Support for fsysopts and multiple interfaces

"Brent W. Baccala" writes: > Joan - > > Thank you for your work on this. I haven't commented on it until now, > partly because of some email problems, and partly because I haven't been > working on Hurd for the last six months or so. > > On Mon, Jun 26, 2017 at 7:28 AM,

Re: Lightly tested patch to make fakeroot obey O_NOFOLLOW

Justus Winter <jus...@gnupg.org> writes: > I haven't had a chance to build packages with it yet, but it makes my > minimal test case happy. With this fix, dkpg builds without problems. I will commit the fix. Justus signature.asc Description: PGP signature

[PATCH hurd] trans/fakeroot: Obey O_NOFOLLOW.

* trans/fakeroot.c (netfs_S_dir_lookup): Do not follow symlinks if the client used O_NOFOLLOW. --- trans/fakeroot.c | 60 +++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/trans/fakeroot.c b/trans/fakeroot.c index

Lightly tested patch to make fakeroot obey O_NOFOLLOW

I haven't had a chance to build packages with it yet, but it makes my minimal test case happy. Justus

Re: [PATCH hurd] trans: Fix parallel build race around MIG-generated headers

David Michael writes: > This causes random.d to be generated which makes random.o depend on > mach_debug_U.h, ensuring it exists before random.c is compiled. > > * trans/Makefile: Add random.c to SRCS when gcrypt is used. Merged, thanks! Justus signature.asc

Re: [GSoC 2017] Work done so far

Hi :) Joan Lledó writes: > It's useful to make a review of the work done in the last months and > list some of the problems arisen during this period. Thank you for your nice writeups, they are appreciated :) > The process of writing the sockets and I/O operations

Re: proc_task2proc prototype change

David Michael <fedora@gmail.com> writes: > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter <jus...@gnupg.org> wrote: >> Samuel Thibault <samuel.thiba...@gnu.org> writes: >> >>> Hello, >>> >>> Justus Winter, on mar. 09 mai 2017 10:2

Re: Hurd's fakeroot seems to break dpkg 1.18.24 testsuite

Hi :) Guillem Jover writes: > I finally got the chance to take a look at the dpkg FTBFS on Hurd (after > recovering my VM! :), and it appears as if it was a fakeroot problem? It is a bug in our fakeroot, it breaks O_NOFOLLOW: teythoon@hurdbox ~ % cat onofollow.c #include

Re: proc_task2proc prototype change

Samuel Thibault <samuel.thiba...@gnu.org> writes: > Hello, > > Justus Winter, on mar. 09 mai 2017 10:25:31 +0200, wrote: >> It is possible to do so using either some preprocessor trickery, >> or some other means of transformation (awk) on the protocol >> specif

Re: proc_task2proc prototype change

Samuel Thibault <samuel.thiba...@gnu.org> writes: > Hello, > > Justus Winter, on mar. 09 mai 2017 10:25:31 +0200, wrote: >> It is possible to do so using either some preprocessor trickery, >> or some other means of transformation (awk) on the protocol >> specif

Re: Revisited: Hurd on a cluster computer

Samuel Thibault <samuel.thiba...@gnu.org> writes: > Justus Winter, on dim. 21 mai 2017 15:39:07 +0200, wrote: >> Samuel Thibault <samuel.thiba...@gnu.org> writes: >> >> > Mark Morgan Lloyd, on sam. 20 mai 2017 12:18:01 +, wrote: >> >> Finally,

Re: Revisited: Hurd on a cluster computer

Samuel Thibault writes: > Mark Morgan Lloyd, on sam. 20 mai 2017 12:18:01 +, wrote: >> Finally, what is the Hurd portability situation? Way back I worked on a >> microkernel in '386 protected mode that used segmentation heavily, am I >> correct in assuming that that

Re: proc_task2proc prototype change

Samuel Thibault <samuel.thiba...@gnu.org> writes: > Justus Winter, on dim. 07 mai 2017 17:42:24 +0200, wrote: >> Can you paste the client code? > > kern_return_t __proc_task2proc > ( > process_t process, > mach_port_t tas

Re: proc_task2proc prototype change

Samuel Thibault writes: > David Michael, on sam. 06 mai 2017 12:28:51 -0700, wrote: >> The new generated functions all get an additional >> "mach_msg_type_name_t *msgportPoly" parameter and none of the callers >> were updated, so they all fail to compile with "too few

[bug #48438] Cannot replace /hurd/fifo with different passive translator

Follow-up Comment #2, bug #48438 (project hurd): That is not what the OP meant. You are seeing this because you accessed the node 'hop' and started the translator. Therefore, you have to use some flag to tell settrans how to deal with the active translator. The OP correctly reported that the

[bug #48890] mach-defpager isn't properly marked important

Update of bug #48890 (project hurd): Status:None => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #5: Yes, this is correct.

Changing our thread model // resource accounting

Hello :) with the recent advancements in Subhurd(TM) technology, our lack of accounting is becoming more and more apparent. The challenge with accounting is of course to attribute resources spent to the client that actually asked some server for some work. Also, with our current thread model

Making Subhurds great again!

Hello :) last year some commie bastard took away the privileges of our Subhurds! Tearable! And worse, the processes of our poor Subhurds were weird looking as before, but no longer debuggable. Sad. But fear not, my friends, for I made Subhurds great again: teythoon@hurdbox ~ % ps PID TT

Re: [PATCH 2/2] Rewrite gsync so that it works with remote tasks v2

Samuel Thibault writes: > Agustina Arzille, on lun. 06 mars 2017 15:24:16 -0300, wrote: >> On 2017-03-04 19:44, Samuel Thibault wrote: >> > (thus related with Brent's "multithread rpctrace to avoid deadlocks in >> > the kernel" patch) >> >> Could be. I'm a bit puzzled

Re: GSoC mentors

Thomas Schwinge writes: > Who will be available this year as a mentor for GSoC? Me. Justus signature.asc Description: PGP signature

Re: drama

Hi, Richard Braun writes: > We're lucky enough to have almost no drama-related issue, thanks in no > small part to the tiny number of contributors. > > But we have Svante Signell. His inability to decently work with others > is known beyond the Hurd, so it should come as no

Re: [PATCH] adding /proc/pid/exe

Samuel Thibault writes: > Hello, > > Samuel Thibault, on Mon 19 Dec 2016 14:38:25 +0100, wrote: >> I'm notably wondering about the RPC: >> should we be using string_t or data_t ? > > So, any opinion on this? I recommend just using string_t for now. Eventually, we need

Re: Time for another round of releases

Thomas Schwinge writes: >> but I'm actually glad we did have a chance to merge >> some more stuff ;) So, anything else missing for Hurd 0.9? > > :-) Seems we're good to go; planning for tomorrow. Cool! > I'll then set the GNU Hurd 0.10 etc. release dates for 2017-06,

Re: Time for another round of releases

Thomas Schwinge writes: > Will it be OK to move the release date towards end of November? (Yay, > one more month for getting stuff finished for inclusion...) ;'-\ Or two (mea culpa), but I'm actually glad we did have a chance to merge some more stuff ;) So, anything

Re: gdb handling of Mach exceptions

"Brent W. Baccala" writes: > On Wed, Nov 23, 2016 at 10:03 PM, Brent W. Baccala > wrote: > >> >> Any comments? >> > > Well, yes, actually. :-) > > gdb's hurd target has a poorly documented command "set noninvasive". I > don't completely understand it,

[bug #17341] booting a sub-hurd as non-root user

Update of bug #17341 (project hurd): Status: Confirmed => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Fixed in

Re: gsync/libihash hash function

Hi, "Brent W. Baccala" writes: > libihash has a similar issue. It seems to use no hash function by default, The main performance critical use of libihash was to map port names (which are mostly consecutive small integers) to objects. I spent some time optimizing libihash

Re: two more rpctrace patches

Hi! "Brent W. Baccala" writes: > I'm attaching two more patches to rpctrace that close bug 48863. Cool. Two nitpicks: 1/ Instead of attaching patches, why don't you use git send-email. That is easier for everyone. 2/ The summary line of your patches is too long, try to

Re: minor bug in glibc

"Brent W. Baccala" writes: > task337(pid1240)->mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid > name) We talked about this briefly on the list, and I remember we agreed that this should be a nop. This needs to be documented and changed in GNU Mach, of course.

Re: Mach "pipe" between parent and child

"Brent W. Baccala" writes: > What is the best way to fork() a child and have a Mach receive right on the > parent connected to a send right on the child? Or vice versa? There is no easy and obvious way that I know. Basically, you need to insert the send right into the

Re: rpctrace design

Hey, I don't have time to look into that in detail now, but "Brent W. Baccala" writes: > I read on the website's hurd/debugging/rpctrace page that somebody (zhenga) > had come with a new version of rpctrace. Do we have a copy of it around > somewhere? We merged his

Re: commit 341f43d: boot: Ignore EINTR.

Hi :) "Brent W. Baccala" writes: > What are the symptoms of this bug? Start a Subhurd, stop the boot program using e.g. gdb, resume it, select got interrupted, boot dies. > I've been seeing sporadic behavior where my boot hangs right after "exec" > prints in the "Hurd

[PATCH gnumach] i386: Use discontiguous page directories when using PAE.

Previously, we used contiguous page directories four pages in length when using PAE. To prevent physical memory fragmentation, we need to use virtual memory for objects spanning multiple pages. Virtual kernel memory, however, is a scarce commodity. * i386/intel/pmap.h (lin2pdenum): Never

Re: Time for another round of releases

Thomas Schwinge <tho...@codesourcery.com> writes: > On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter <jus...@gnupg.org> wrote: >> it is October, therefore, it is time for a new set of releases :) > > Will it be OK to move the release date towards end of November? Sure

[bug #48930] crash server crashes after --core-file-name is changed with fsysopts

Update of bug #48930 (project hurd): Open/Closed:Open => Closed ___ Reply to this item at: ___

Time for another round of releases

Hello, it is October, therefore, it is time for a new set of releases :) I'll be going over the changes and update the NEWS files as usual, but feel free to beat me to that. Also, if anyone has some pet patches or fixes that would be nice to include, feel free to speak up or send patches.

panic: pmap_page_protect removing a wired page

Hello, we spoke briefly in #hurd about a problem with wired memory I encountered during my work on the malleable syscall interface. I managed to create a more minimal test case. The attached program crashes stock Mach kernels as packaged by Debian. Cheers, Justus signature.asc Description:

Re: [PATCH gnumach] RFC: Create a malleable syscall interface.

"Brent W. Baccala" <cos...@freesoft.org> writes: > On Thu, Sep 22, 2016 at 12:21 PM, Justus Winter <jus...@gnupg.org> wrote: > >> >> % ~/build/machometer/machometer >> N: 33554432 (1<<25), qlimit: 5 >> mach_print: 5s75us171

[PATCH gnumach] RFC: Create a malleable syscall interface.

From: Justus Winter <4win...@informatik.uni-hamburg.de> Currently, GNU Mach uses trap gates on i386 which are known to be slow compared to modern alternatives like SYSENTER/SYSEXIT from Intel or SYSCALL/SYSRET from AMD. To make use of these instructions, we need to detect at runtime w

[bug #49056] sending mach_port_kernel_object to non-task object crashes mach

Update of bug #49056 (project hurd): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks for the report, fixed in 25d5ceed. I must ask though, in the time it has taken you to file

Re: problems with a subhurd

Hey :) "Brent W. Baccala" writes: > Our current setup is that PID 5 (ext2fs) runs first, then starts PID 2 > (startup), which starts PID 1 (init). Weird. The cleanest solution, of > course, would be to have proc actually respect these parenting > relationships, then

Re: Fwd: Hurd shutdown problems

Hello, "Brent W. Baccala" writes: > Further progress trying to track this down: > > I don't have to shutdown the system to have problems. "swapoff /dev/hd0s5" > is enough to cause problems, once enough swap is in use. After a failed > swapoff, I have an extra 98 storeio

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Richard Braun <rbr...@sceen.net> writes: > On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote: >> Richard Braun <rbr...@sceen.net> writes: >> > Why not start the translator from the remapped environment too ? >> >> No reason, but this

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Richard Braun <rbr...@sceen.net> writes: > On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote: >> Right, I can see how this is a problem. The thing is, remap doesn't >> quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a >>

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Christian Seiler writes: Use the remap translator instead, which is one of the things the Hurd design allows you to do easily. See /bin/remap to easily set one. >>> >>> remap doesn't work at all here, programs then complain >>> that they can't assign

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Christian Seiler writes: > (The following is not really important, rebooting does > work, so it's not a showstopper.) > > On 08/07/2016 09:13 PM, Richard Braun wrote: >> On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote: PS: Is there any way to sanely restart

Re: Hurd shutdown problems

"Brent W. Baccala" <cos...@freesoft.org> writes: > On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter <jus...@gnupg.org> wrote: > >> >> To prevent filesystem damage, try the following. Break into the kernel >> debugger, and kill the auth server using: >

Re: Hurd shutdown problems

Please use a MUA that does not break threads like this. Esa Peuha writes: > Have you tried using halt-hurd instead of shutdown? As far as I can > remember, halt-hurd has never caused file system corruption for me, > but I'm pretty sure shutdown did way back when I was still

Re: Hurd shutdown problems

Hi :) "Brent W. Baccala" writes: > Aloha! > > Well, I think that I've resolved my boot hangs by removing the > -no-kvm-irqchip flag, now I'm trying to resolve the occasional hang when > the system shuts down. The filesystem always gets corrupted if the system > can't

Re: [bug #48685] update-grub triggers filesystem server panics

"Brent W. Baccala" <cos...@freesoft.org> writes: > On Tue, Aug 2, 2016 at 9:52 PM, Justus Winter <invalid.nore...@gnu.org> > wrote: > >> >> The isofs crash is fixed in 21ee0e79. Please update your Hurd packages. >> >> The fact that you are s

[bug #48685] update-grub triggers filesystem server panics

Update of bug #48685 (project hurd): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: The isofs crash is

Re: [PATCH] i386: Omit pmap workaround on i486 or later.

Hi :) Masanori Ogino writes: > How about this patch? > Did I share this with you in a wrong way, or is it simply useless? > > 2016-06-18 22:04 GMT+09:00 Masanori Ogino : >> As described in XXX comments, the workaround for memory mapping is >>

[task #2561] Restrict hurd_ihash_add function

Update of task #2561 (project hurd): Should Start On: => Mon 04 Jul 2016 12:00:00 AM GMT Should be Finished on: => Mon 04 Jul 2016 12:00:00 AM GMT Status:None => Need Info

Re: RFC: Runtime checking of port handling

Hi, Quoting Samuel Thibault (2016-06-04 17:32:06) > Justus Winter, on Sat 04 Jun 2016 15:45:15 +0200, wrote: > > tl;dr: Compiler-assisted runtime checking of port handling in > > variables with automatic storage duration. Do we want to go there? > > That's interesting,

[PATCH hurd 2/2] libshouldbeinlibc: add safe port handling macros

* libshouldbeinlibc/Makefile (SRCS, installhdrs): Add new file. * libshouldbeinlibc/machx.h: New file. --- libshouldbeinlibc/Makefile | 2 ++ libshouldbeinlibc/machx.h | 73 ++ trans/crash.c | 29 +- 3 files changed, 89

[PATCH hurd 1/2] xxx print fail

--- libshouldbeinlibc/assert-backtrace.c | 8 libshouldbeinlibc/assert-backtrace.h | 6 ++ 2 files changed, 14 insertions(+) diff --git a/libshouldbeinlibc/assert-backtrace.c b/libshouldbeinlibc/assert-backtrace.c index ca23c8d..72a49e9 100644 ---

RFC: Runtime checking of port handling

Hello :) tl;dr: Compiler-assisted runtime checking of port handling in variables with automatic storage duration. Do we want to go there? Long version: I recently found a pretty bad resource leak in our crash server and pondered how to find such issues proactively. The main idea is to 1/

Re: [PATCH] libhurdutil: New library containing utils to be used by Guix.

Hi :) Quoting manolis...@gmail.com (2016-05-25 17:05:57) > From: Manolis Ragkousis > > * libhurdutil/hurdutil.h: New file. > * libhurdutil/settrans.c: New file. > * libhurdutil/Makefile: New file. > * utils/Makefile (HURDLIBS, settrans): Use the new library. > *

Re: [PATCH] libhurdutil: New library containing utils to be used by Guix.

Quoting manolis...@gmail.com (2016-05-25 17:05:56) > > I am resending the patch from > https://lists.gnu.org/archive/html/bug-hurd/2016-05/msg00040.html modified to > apply on master. git send-email --in-reply-to=MSGIDGOESHERE is your friend ;) Justus

Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager

Quoting Justus Winter (2016-05-18 13:27:13) > > Backing up one step: what is actually being done here in mach-defpager? > > Again from just a quick look, is the idea to use wired memory for all of > > mach-defpager's process memory? Yes, wiring the memory is required to avoid

Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager

Hey :) Quoting Thomas Schwinge (2016-05-16 18:49:47) > Hi! > > On Tue, 29 Dec 2015 23:09:54 +0100, Flavio Cruz wrote: > > mach-defpager: Drop the deprecated malloc/free hooks. > > (After approval by Samuel, this became commit > 8c49801c8f7e3f800cabedf8fca8ccec3cf35a22.) >

Re: ext2fs crash

Hi, Quoting Thomas Schwinge (2016-05-13 23:02:08) > Hi! > > On Mon, 09 May 2016 16:11:52 +0200, Justus Winter > <4win...@informatik.uni-hamburg.de> wrote: > > Quoting Thomas Schwinge (2016-04-27 22:53:33) > > > [...] > > > I suppose we want to fix (or

Re: ext2fs crash

Hi :) Quoting Thomas Schwinge (2016-04-27 22:53:33) > Before preparing the next set of releases, I wanted to sort-of > sanity-check what we currently got (at least in terms of Debian > packages), so yesterday dist-upgraded my Debian GNU/Hurd system to the > latest packages, and started a GCC

Re: Minor bug introduced by commit b04364b

Quoting Esa Peuha (2016-05-06 18:39:11) > Most changes in commit b04364b seem to be fine, but this one isn't: > > @@ -405,7 +401,7 @@ run (const char *server, mach_port_t *ports, task_t *task) > } > >if (verbose) > -fprintf (stderr, "started %s\n", prog); > +fprintf (stderr,

Re: [PATCH] Simple testsuite for MIG.

Quoting Flavio Cruz (2016-04-19 01:48:50) > This includes a set of valid and invalid definition files that MIG will > try to process. For valid definitions, GCC will compile the stubs to > check if valid C code was generated. Merged, many thanks :) Justus

Re: [PATCH] Use uint32_t instead of unsigned32_t.

Quoting Flávio Cruz (2016-04-05 01:05:43) > On 5 April 2016 at 00:59, Justus Winter <4win...@informatik.uni-hamburg.de> > wrote: > > > Quoting Justus Winter (2016-04-05 00:46:11) > > > Quoting Flávio Cruz (2016-04-05 00:39:48) > > > > > This broke your

Re: [PATCH] Use uint32_t instead of unsigned32_t.

Quoting Justus Winter (2016-04-05 00:46:11) > Quoting Flávio Cruz (2016-04-05 00:39:48) > > > This broke your test suite: > > Should work with the new patch. Thanks for the report. > > It does indeed. Furthermore, I was able to build a seemingly working Hurd package us

Re: [PATCH] Use uint32_t instead of unsigned32_t.

Quoting Flávio Cruz (2016-04-05 00:39:48) > > This broke your test suite: > Should work with the new patch. Thanks for the report. It does indeed. Thanks, Justus

Re: [PATCH] Use posix types for mig definitions.

Quoting Flavio Cruz (2016-03-15 10:49:51) > * hurd/hurd_types.defs: Use posix types. > * libfshelp/start-translator-long.c: Use uint32_t instead of > unsigned32_t. This broke the Debian/Hurd package build. Justus

Re: [PATCH] Use uint32_t instead of unsigned32_t.

Quoting Flavio Cruz (2016-03-20 22:01:10) > * Makefile.am: Use -ffreestanding and remove -nostdinc since we are including > stdint.h. > * i386/i386/xen.h: Use uint64_t. > * i386/include/mach/i386/machine_types.defs: Use uint32_t and int32_t. > * i386/include/mach/i386/vm_types.h: Remove

Re: [PATCH] Use uint32_t instead of unsigned32_t.

Quoting Flavio Cruz (2016-03-15 10:48:48) > * utils.c: Generate code using uint32_t. > --- > utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/utils.c b/utils.c > index 4c2a87b..ccde966 100644 > --- a/utils.c > +++ b/utils.c > @@ -77,7 +77,7 @@

Re: [PATCH] Turn mach_msg_type_{name,size}_t into unsigned chars.

Quoting Samuel Thibault (2016-04-04 09:16:17) > Hello, > > Flavio Cruz, on Sun 03 Apr 2016 16:12:48 +0200, wrote: > > mach_msg_type_name_t and mach_msg_type_size_t are used as 8 bit fields in > > mach_msg_type_t struct, therefore they should be treated as unsigned char's > > to > > avoid

Re: [PATCH] Simple testsuite for MIG.

I like it a lot. May I suggest the following robustness fix? Seems like the empty files are lost somewhere in my ci/package building setup. Also I think we want copyright notices at least in the framework files, not sure about the test vectors. Thougths? Justus

[PATCH mig] Robustness fix.

--- tests/includes/all.h| 1 + tests/includes/server.h | 1 + tests/includes/user.h | 1 + 3 files changed, 3 insertions(+) diff --git a/tests/includes/all.h b/tests/includes/all.h index e69de29..6e25b02 100644 --- a/tests/includes/all.h +++ b/tests/includes/all.h @@ -0,0 +1 @@ +/* Empty.

Re: [PATCH] Simple testsuite for MIG.

Definition files with some mistakes that should be > recognized by MIG. > --- > > Hey, > > On Wed, Mar 23, 2016 at 11:17:03AM +0100, Justus Winter wrote: > > Quoting Flavio Cruz (2016-03-23 01:31:13) > > > This includes a set of valid and invalid defini

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hi, Quoting Manolis Ragkousis (2016-03-24 14:55:31) > On 03/24/16 15:22, Ludovic Courtès wrote: > >>> The main question is whether you should implement build isolation in > >>> guix-daemon, in which case that would leave little time for the GuixSD > >>> parts. I think I would rather let you

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Quoting Manolis Ragkousis (2016-03-24 12:18:25) > >>> The project consists of four main stages > >>> > >>> 1. Modify Guix so it will be able to create and mount the file-system > >>> needed to boot into a system with Hurd at its core. > >>> 2. Modify Guix so it can produce a working image, while

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hi, Quoting Ludovic Courtès (2016-03-23 14:40:38) > > 2. The Project > > > > The project consists of four main stages > > > > 1. Modify Guix so it will be able to create and mount the file-system > > needed to boot into a system with Hurd at its core. > > 2. Modify Guix so it can produce a

Re: Dangerous use of alloca

Hi, Quoting Agustina Arzille (2016-03-16 02:44:28) > As promised, here's the patch to avoid the aforementioned alloca bugs. > It's a bit of an overkill, imo, but it does support ridiculously long > command-line arguments =D It is way too complicated. We don't need to be efficient here. Also,

Re: [PATCH] Automatically generate parser.h.

Quoting Flavio Cruz (2016-03-14 21:22:34) > * Makefile.am: Set AM_YFLAGS to -d to generate parser.h. Add parser.h to > CLEANFILES and include parser.h as a dependency of lexxer.c. > * lexxer.l: Declare yyerror here. > * parser.h: Remove file since yacc will generate the same content >

Re: Dangerous use of alloca

Quoting Samuel Thibault (2016-03-15 18:30:16) > Justus Winter, on Tue 15 Mar 2016 18:10:18 +0100, wrote: > > Quoting Samuel Thibault (2016-03-15 17:31:53) > > > Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote: > > > > Quoting Agustina Arzille (2016-03-15 14:11

Re: Dangerous use of alloca

Quoting Samuel Thibault (2016-03-15 17:31:53) > Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote: > > Quoting Agustina Arzille (2016-03-15 14:11:27) > > > Hello, everyone. > > > > > > I was browsing some gnumach source files, and noticed some dangerous

Re: Dangerous use of alloca

Quoting Agustina Arzille (2016-03-15 15:44:13) > > Good catch. However, alloca is dangerous even if used correctly, and > > is best be avoided. Would you be so kind to prepare a patch to that > > end? > > > > Thanks, > > Justus > > Sure. I will cook up a patch when I get home. Right now, the

Re: Dangerous use of alloca

Hi, Quoting Agustina Arzille (2016-03-15 14:11:27) > Hello, everyone. > > I was browsing some gnumach source files, and noticed some dangerous use > of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212 and > 228, we have the following statement: > > memcpy (alloca (len), ...)

Re: fakeroot-hurd doesn't work with scripts

Quoting Samuel Thibault (2016-03-07 20:49:01) > Justus Winter, on Mon 07 Mar 2016 20:30:37 +0100, wrote: > > teythoon@hurdbox ~ % for x in sh py pl; do cat test.$x ; fakeroot ./test.$x > > ; done > > I should have mentioned it: the issue is only for scripts coming from >

Re: fakeroot-hurd doesn't work with scripts

Hi, Quoting Samuel Thibault (2016-03-04 18:39:21) > We have an issue between fakeroot and scripts (from the borgbackup build > log): > > > fakeroot dh_auto_test > > Can't open perl script "dh_auto_test": No such file or directory > > I guess that's due to the way fakeauth starts the program, I

Re: refcounts assertion

Quoting Samuel Thibault (2016-03-07 01:40:01) > Hello, > > Some kind of refcount assertion failure we have been having is "refcount > detected use-after-free!" from the call to refcounts_ref inside > _ports_bucket_class_iterate, called for instance by the periodic sync. > I'm thinking: what about

  1   2   3   4   5   6   7   8   9   10   >