Re: upstream GNU Hurd vs Debian GNU Hurd?

[Ludovic Courtès]

Hello!

Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> Quoting Samuel Thibault (2013-09-09 10:04:55)

[...]

>> > Also, according to [0] Debian/Hurd is the only "working" Hurd
>> > distribution (whatever that means, let's say not in "early stages of
>> > development" and not "defunct" as used on that page). In particular,
>> > the "GNU" distribution is marked as "defunct" and according to [1]
>> > there has not been a release for seven years. So from my point of view
>> > they are *not* using /hurd/init as reaper, so they might as well *not*
>> > use sysvinit (or any other established init system) as reaper.
>> 
>> Actually Guix is on its way to become a GNU distribution, and some
>> preliminary work has already been done on the Nix side, it does work a
>> bit.  AIUI, there are people motivated on working on that distribution,
>> which would become a GNU system using the Hurd.

More precisely: by the end of the year, we’ll have the GNU system on top
of Linux-Libre.

The goal has always been to support the Hurd in addition to Linux-Libre.
However, we have the policy of only packaging upstream releases, and
there is none for the Hurd (hint, hint!).

> I don't buy it ;)
>
> /hurd/init is not an init system, it barely does anything any other
> init system does. From my point of view its name is the only thing
> that it has in common with other init systems, and it should really be
> named /hurd/startup or /hurd/bootstrap or something as it really
> mostly bootstraps a couple of processes running atop of mach into
> something resembling a POSIX system. If GNU wants a sysvinit
> replacement, they will have to write one.

Granted, the Hurd’s rc.sh is minimalist, and probably lacking some
features.  But the beauty of GNU/Hurd is that typical startup
configuration (networking, system services, etc.) is stored in a
distributed fashion in the file system, as passive translator settings.
So rc.sh or anything equivalent can remain very simple.

Interestingly, an acclaimed feature of systemd is its “automount units”,
which allow a service to be started upon access to a mount point–does
that ring a bell?  :-)

> Out of curiousity I browsed the GUIX package list, and I couldn't find
> an init system in there. How do they even boot the system? I did find
> the linux-libre kernel though, so if GUIX wants to run ontop of both
> Linux and Hurd, they will have to find/write an init replacement that
> runs on both. Even if /hurd/init was an init system, it surely does
> not and never will run on Linux.

GNU will be using dmd as its init system
(cf. ).  Of course we have yet to gain
more experience with that, so time will tell what additional
developments need to be done to overcome any limitations.  However, the
overall design of dmd is well-documented and sound, AFAICS.

Anyway, this is all work-in-progress, and it would be great to see
active discussion about these topics on gnu-system-disc...@gnu.org.  So
please join in and speak up!  :-)

Thanks,
Ludo’.

[PATCH 3/5] track the console init with a boolean instead of an int

[Marin Ramesa]

A variable that keeps track if the console init has been called. It should
never receive values other than 0 and 1, so constrain it's possible range of 
values to a boolean.

* device/cons.c (cn_inited): Use boolean_t instead of an int.

---
 device/cons.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/device/cons.c b/device/cons.c
index a220723..ceba7f2 100644
--- a/device/cons.c
+++ b/device/cons.c
@@ -32,7 +32,7 @@
 #include 
 #endif
 
-static int cn_inited = 0;
+static boolean_t cn_inited = FALSE;
 static struct consdev *cn_tab = 0; /* physical console device info */
 
 /*
@@ -109,7 +109,7 @@ cninit()
consbufused = FALSE;
}
 #endif
-   cn_inited = 1;
+   cn_inited = TRUE;
return;
}
/*
-- 
1.8.1.4

[PATCH 2/5] track the console buffer usage with a boolean instead of an int

[Marin Ramesa]

A variable that keeps track of the console buffer usage should never receive 
values other than 0 and 1, so constrain it's value range to boolean. Plus, it's
more readable this way.

* device/cons.c (consbufused): Use boolean_t instead of an int.

---
 device/cons.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/device/cons.c b/device/cons.c
index f26f22c..a220723 100644
--- a/device/cons.c
+++ b/device/cons.c
@@ -54,7 +54,7 @@ void  (*romputc)() = 0;
  */
 static char consbuf[CONSBUFSIZE] = { 0 };
 static char *consbp = consbuf;
-static int consbufused = 0;
+static boolean_t consbufused = FALSE;
 #endif
 
 void
@@ -106,7 +106,7 @@ cninit()
if (++cbp == &consbuf[CONSBUFSIZE])
cbp = consbuf;
} while (cbp != consbp);
-   consbufused = 0;
+   consbufused = FALSE;
}
 #endif
cn_inited = 1;
@@ -171,9 +171,9 @@ cnputc(c)
}
 #if CONSBUFSIZE > 0
else {
-   if (consbufused == 0) {
+   if (consbufused == FALSE) {
consbp = consbuf;
-   consbufused = 1;
+   consbufused = TRUE;
memset(consbuf, 0, CONSBUFSIZE);
}
*consbp++ = c;
-- 
1.8.1.4

[PATCH 4/5] qualify constant with the const

[Marin Ramesa]

Function cnputc() should never modify it's argument so qualify it
with a const keyword.

* device/cons.c (cnputc): Qualify argument as const.
* device/cons.h (cnputc): Likewise.

---
 device/cons.c | 2 +-
 device/cons.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/device/cons.c b/device/cons.c
index ceba7f2..94d4ebf 100644
--- a/device/cons.c
+++ b/device/cons.c
@@ -141,7 +141,7 @@ cnmaygetc()
 
 void
 cnputc(c)
-   char c;
+   const char c;
 {
if (c == 0)
return;
diff --git a/device/cons.h b/device/cons.h
index 8ac796c..32a8739 100644
--- a/device/cons.h
+++ b/device/cons.h
@@ -53,5 +53,5 @@ extern int cngetc(void);
 
 extern int cnmaygetc(void);
 
-extern void cnputc(char);
+extern void cnputc(const char);
 #endif /* _DEVICE_CONS_H */
-- 
1.8.1.4

[PATCH 1/5] drop unused CONSMAJOR

[Marin Ramesa]

CONSMAJOR is never used. I'm guessing that in the past it was
a part of some problematic code. I don't see a reason to keep 
it's definition.

* device/cons.h (CONSMAJOR): Remove definition.

---
 device/cons.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/device/cons.h b/device/cons.h
index 6a0ae85..8ac796c 100644
--- a/device/cons.h
+++ b/device/cons.h
@@ -41,9 +41,6 @@ struct consdev {
 #define CN_INTERNAL2   /* "internal" bit-mapped display */
 #define CN_REMOTE  3   /* serial interface with remote bit set */
 
-/* XXX */
-#defineCONSMAJOR   0
-
 #define CONSBUFSIZE1024
 
 #ifdef KERNEL
-- 
1.8.1.4

Some cleanup of the console code

[Marin Ramesa]

What follows is a small cleanup of the console code.

[PATCH 1/5] drop unused CONSMAJOR
[PATCH 2/5] track the console buffer usage with a boolean instead of an int
[PATCH 3/5] track the console init with a boolean instead of an int
[PATCH 4/5] qualify constant with the const
[PATCH 5/5] remove hyp_console_write() call

[PATCH 5/5] remove hyp_console_write() call

[Marin Ramesa]

Please comment on this removal.

The check 'defined(MACH_HYP) && 0' never evaluates to TRUE, so
I'm guessing this was a way to comment out this code. I don't
see hyp_console_write() anywhere defined except in xen, so there
should be some checking for that too. Plus, the call itself look like 
it needs some rewrite.

I'm not sure about this removal, so if there is a reason to keep
this code, please ignore this patch.

* device/cons.c [defined(MACH_HYP) && 0]: Remove hyp_console_write() call.

---
 device/cons.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/device/cons.c b/device/cons.c
index 94d4ebf..92f1481 100644
--- a/device/cons.c
+++ b/device/cons.c
@@ -151,15 +151,6 @@ cnputc(c)
kmsg_putchar (c);
 #endif

-#if defined(MACH_HYP) && 0
-   {
-   /* Also output on hypervisor's emergency console, for
-* debugging */
-   unsigned char d = c;
-   hyp_console_write(&d, 1);
-   }
-#endif /* MACH_HYP */
-   
if (cn_tab) {
(*cn_tab->cn_putc)(cn_tab->cn_dev, c);
if (c == '\n')
-- 
1.8.1.4

Re: Hacking gnumach to track parental relationship of tasks

[Justus Winter]

Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-10 20:00:32)
> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
> 
> > Quoting Samuel Thibault (2013-09-09 19:40:23)
> >> Ludovic Courtès, le Mon 09 Sep 2013 18:48:03 +0200, a écrit :
> >> > Samuel Thibault  skribis:
> >> > > Ludovic Courtès, le Sat 07 Sep 2013 22:04:06 +0200, a écrit :
> >> > >> However, wouldn’t it be preferable to fix it by interposing on
> >> > >> ‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done 
> >> > >> with
> >> > >> by setting the TASK_KERNEL_PORT of a task.)
> >> > >
> >> > > Apparently task_create is a kernel trap.
> >> > 
> >> > Isn’t rpctrace able to interpose on it?
> >> 
> >> I don't think there is any way to interpose a trap.
> >> 
> >> It probably happens that libc nicely uses the RPC, but nothing prevents
> >> a process from raising a trap.
> >
> > As I understand [0] one can interpose all Mach system calls
> 
> Yes, and ‘task_create’ is no exception to the rule:
> 
> --8<---cut here---start->8---
> ludo@darnassus:~$ rpctrace -o ,,s sh -c 'sleep 2 & true'

This is all very fascinating, but completely unrelated. Have you
looked at [0]? Have you looked at rpctrace?

> So what about using that technique to achieve what you want?  :-)

Besides me having second thoughts about using this on every process on
the system (this is the part of my message that you conveniently left
out while quoting btw)? Well, if anyone can set the emulation vector,
how do you prevent any process from clearing your interception
function? By intercepting the setting of the emulation vector and
replicating the emulation yourself?

Btw, I was curious how apple deals with this. They don't. They
outright forbid task_create, I guess everyone has to go through their
os server that creates a task that is attached to a process structure
from the beginning.

Justus

Re: [PATCH 5/5] remove hyp_console_write() call

[Samuel Thibault]

Marin Ramesa, le Wed 11 Sep 2013 12:27:51 +0200, a écrit :
> The check 'defined(MACH_HYP) && 0' never evaluates to TRUE, so
> I'm guessing this was a way to comment out this code.

Yes.  This is meant to be used for whoever would need to debug very
early initialization of Mach as a Xen domU.

Samuel

Re: Some cleanup of the console code

[Samuel Thibault]

Marin Ramesa, le Wed 11 Sep 2013 12:27:46 +0200, a écrit :
> [PATCH 1/5] drop unused CONSMAJOR
> [PATCH 2/5] track the console buffer usage with a boolean instead of an int
> [PATCH 3/5] track the console init with a boolean instead of an int

Applied these, thanks.

Samuel

Re: [PATCH 4/5] qualify constant with the const

[Samuel Thibault]

Marin Ramesa, le Wed 11 Sep 2013 12:27:50 +0200, a écrit :
> Function cnputc() should never modify it's argument so qualify it
> with a const keyword.
> 
>  void
>  cnputc(c)
> - char c;
> + const char c;

Well, this is not really useful: the function gets a copy of the
argument anyway.

Samuel

Re: Hacking gnumach to track parental relationship of tasks

[Ludovic Courtès]

Justus Winter <4win...@informatik.uni-hamburg.de> skribis:

> Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-10 20:00:32)
>> Justus Winter <4win...@informatik.uni-hamburg.de> skribis:
>> 
>> > Quoting Samuel Thibault (2013-09-09 19:40:23)
>> >> Ludovic Courtès, le Mon 09 Sep 2013 18:48:03 +0200, a écrit :
>> >> > Samuel Thibault  skribis:
>> >> > > Ludovic Courtès, le Sat 07 Sep 2013 22:04:06 +0200, a écrit :
>> >> > >> However, wouldn’t it be preferable to fix it by interposing on
>> >> > >> ‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done 
>> >> > >> with
>> >> > >> by setting the TASK_KERNEL_PORT of a task.)
>> >> > >
>> >> > > Apparently task_create is a kernel trap.
>> >> > 
>> >> > Isn’t rpctrace able to interpose on it?
>> >> 
>> >> I don't think there is any way to interpose a trap.
>> >> 
>> >> It probably happens that libc nicely uses the RPC, but nothing prevents
>> >> a process from raising a trap.
>> >
>> > As I understand [0] one can interpose all Mach system calls
>> 
>> Yes, and ‘task_create’ is no exception to the rule:
>> 
>> --8<---cut here---start->8---
>> ludo@darnassus:~$ rpctrace -o ,,s sh -c 'sleep 2 & true'
>
> This is all very fascinating, but completely unrelated. Have you
> looked at [0]? Have you looked at rpctrace?

(Please let’s keep the tone cordial, we’re both trying to be
constructive, I think.)

I was not referring to syscall emulation, but to ‘task_set_special_port’
with the TASK_KERNEL_PORT flag, which is how rpctrace interposes on all
RPCs including those normally served by the kernel, IIUC.

>> So what about using that technique to achieve what you want?  :-)
>
> Besides me having second thoughts about using this on every process on
> the system (this is the part of my message that you conveniently left
> out while quoting btw)?

You wrote:

  Then again, I do not think it is meant as a mechanism to change the
  semantic of one system call for all processes and I do not know the
  performance implications of this mechanism.

In the case we discuss here, the semantics of ‘task_create’ would be
preserved.

There’s surely a performance impact, that would have to be measured.
Now, how bad is it compared to, say, calling user-space ethernet drivers
vs. in-kernel drivers?  :-)

> Well, if anyone can set the emulation vector, how do you prevent any
> process from clearing your interception function? By intercepting the
> setting of the emulation vector and replicating the emulation
> yourself?

Yes, or just by making it a no-op, no?

(I think the problem also arises with the patch your proposed, no?)

Thanks,
Ludo’.

Re: [PATCH 2/2] remove register qualifiers.

[Samuel Thibault]

Marin Ramesa, le Tue 10 Sep 2013 10:38:05 +0200, a écrit :
> * device/cirbuf.c: Remove register qualifiers.

Applied, thanks.

Samuel

Re: Hacking gnumach to track parental relationship of tasks

[Samuel Thibault]

Ludovic Courtès, le Wed 11 Sep 2013 19:59:24 +0200, a écrit :
> In the case we discuss here, the semantics of ‘task_create’ would be
> preserved.
> 
> There’s surely a performance impact, that would have to be measured.
> Now, how bad is it compared to, say, calling user-space ethernet drivers
> vs. in-kernel drivers?  :-)

Possibly big: if we are to interpose *all* kernel traps, that means
interposing vm_allocate/deallocate and such, and IPC might suffer quite
a bit. Userland network drivers only have impact on network bandwidth,
not on *all* operations.

Samuel

Re: [PATCH 1/2] qualify constants as const

[Samuel Thibault]

Marin Ramesa, le Tue 10 Sep 2013 10:38:04 +0200, a écrit :
>  #if  DEBUG
> -int cb_check_enable = 0;
> +const int cb_check_enable = 0;

I'd rather not.

It is useful to be able to modify the value "live" from the debugger, so
as to enable the check only for some time while debugging.

>  #define  CB_CHECK(cb) if (cb_check_enable) cb_check(cb)
>  
>  void
> -- 
> 1.8.1.4
> 
> 

Re: Hacking gnumach to track parental relationship of tasks

[Richard Braun]

On Mon, Sep 09, 2013 at 09:45:18AM +0200, Samuel Thibault wrote:
> Ludovic Courtès, le Sat 07 Sep 2013 22:04:06 +0200, a écrit :
> > However, wouldn’t it be preferable to fix it by interposing on
> > ‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done with
> > by setting the TASK_KERNEL_PORT of a task.)
> 
> Apparently task_create is a kernel trap.

How come it appears in the output of rpctrace then ?

-- 
Richard Braun

Re: [PATCH 1/2] Port gdbserver to GNU/Hurd

[Yue Lu]

Hi,

On Sat, Sep 7, 2013 at 2:53 AM, Pedro Alves  wrote:
> This is what I meant:
> https://sourceware.org/ml/gdb-patches/2013-09/msg00253.html
>
> I was thinking you'd wrap gnu_xfer_memory.
>

I have study your patch, but I found there is no to_xfer_partial field
or something similar in gdbserver's structure target_obj, how can I
do? Please give me more hints, thanks.

> But I have to say I don't really understand the real need for
> all those:
>
>   task_t task = (gnu_current_inf
>  ? (gnu_current_inf->task
> ? gnu_current_inf->task->port : 0)
>  : 0);
>   int res;
>
>   if (task == MACH_PORT_NULL)
> return 0;
>
> checks in the existing code.  I mean, why would we reach here with
> an invalid inferior/task/port selected?
> It just reads as workaround for some bug to me.

Honestly to say, I have copied them from function gnu_xfer_memory. But
I think, before reference a pointer, check whether it was a NULL seems
not a bad way :-).

And this is my update patch which is base on the current upstream master branch.
==
gdbserver
* configure.ac (host_makefile_frag): New rule for GNU/Hurd to load
i386gnu.mh.
* configure.srv (srv_tgtobj): Add gnu-nat.o i386gnu-nat.o. for
GNU/Hurd.
(srv_regobj): Add $(srv_i386_regobj) for GNU/Hurd.
(srv_xmlfiles): Add $(srv_i386_xmlfiles) for GNU/Hurd.
* configure: Regenerate.
* Makefile.in (OBS): Add $(NATDEPFILES).
(generated_files): Add $(NAT_GENERATED_FILES).
(@host_makefile_frag@): New rule, add i386gnu.mh.
(MIG): New tools.
(AWK): New tools.
* utils.c (host_address_to_string): New functions, copy from
[gdb]/gdb/utils.c.

diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in
index 1805e5a..6da44d1 100644
--- a/gdb/gdbserver/Makefile.in
+++ b/gdb/gdbserver/Makefile.in
@@ -50,6 +50,8 @@ INSTALL_DATA = @INSTALL_DATA@
 RANLIB = @RANLIB@

 CC = @CC@
+MIG = @MIG@
+AWK = @AWK@

 # Dependency tracking information.
 DEPMODE = @CCDEPMODE@
@@ -176,7 +178,7 @@ OBS = agent.o ax.o inferiors.o regcache.o
remote-utils.o server.o signals.o \
   target.o waitstatus.o utils.o version.o vec.o gdb_vecs.o \
   mem-break.o hostio.o event-loop.o tracepoint.o xml-utils.o \
   common-utils.o ptid.o buffer.o format.o filestuff.o dll.o notif.o \
-  tdesc.o $(XML_BUILTIN) $(DEPFILES) $(LIBOBJS)
+  tdesc.o $(XML_BUILTIN) $(DEPFILES) $(LIBOBJS) $(NATDEPFILES)
 GDBREPLAY_OBS = gdbreplay.o version.o
 GDBSERVER_LIBS = @GDBSERVER_LIBS@
 XM_CLIBS = @LIBS@
@@ -199,6 +201,11 @@ CLEANDIRS = $(SUBDIRS)
 # The format here is for the `case' shell command.
 REQUIRED_SUBDIRS = $(GNULIB_BUILDDIR)

+# Host-dependent makefile fragment comes in here.
+GDBSERVER_HURD=@GDBSERVER_HURD@
+@host_makefile_frag@
+# End of host-dependent makefile fragment
+
 FLAGS_TO_PASS = \
  "prefix=$(prefix)" \
  "exec_prefix=$(exec_prefix)" \
@@ -232,7 +239,7 @@ FLAGS_TO_PASS = \
  "RUNTESTFLAGS=$(RUNTESTFLAGS)"

 # All generated files which can be included by another file.
-generated_files = config.h $(GNULIB_H)
+generated_files = config.h $(GNULIB_H) $(NAT_GENERATED_FILES)

 .c.o:
  $(COMPILE) $<
@@ -522,6 +529,16 @@ mips-linux-watch.o: ../common/mips-linux-watch.c
  $(COMPILE) $<
  $(POSTCOMPILE)

+ifdef GDBSERVER_HURD
+#fixme, if use i386gnu-nat.o here will complain that can't find rule
for target i386gnu-gnu.c
+i386gnu-nat_foo.o: $(srcdir)/../i386gnu-nat.c
+ $(COMPILE) $<
+ $(POSTCOMPILE)
+gnu-nat.o: $(srcdir)/../gnu-nat.c
+ $(COMPILE) $<
+ $(POSTCOMPILE)
+endif
+
 # Native object files rules from ../nat

 linux-waitpid.o: ../nat/linux-waitpid.c
@@ -535,6 +552,9 @@ linux-waitpid.o: ../nat/linux-waitpid.c
 vasprintf.o: $(srcdir)/../../libiberty/vasprintf.c
  $(COMPILE) $< -DHAVE_CONFIG_H
  $(POSTCOMPILE)
+obstack.o: $(srcdir)/../../libiberty/obstack.c
+ $(COMPILE) $< -DHAVE_CONFIG_H
+ $(POSTCOMPILE)
 vsnprintf.o: $(srcdir)/../../libiberty/vsnprintf.c
  $(COMPILE) $<
  $(POSTCOMPILE)
diff --git a/gdb/gdbserver/configure.ac b/gdb/gdbserver/configure.ac
index 456a1f7..7d4eb75 100644
--- a/gdb/gdbserver/configure.ac
+++ b/gdb/gdbserver/configure.ac
@@ -471,6 +471,31 @@ if $want_ipa ; then
fi
 fi

+frags=
+GDBSERVER_HURD=1
+case $host_os in
+  gnu*)
+#Needed for GNU Hurd hosts.
+AC_PROG_AWK
+AC_CHECK_TOOL(MIG, mig)
+if test x"$MIG" = x; then
+  AC_MSG_ERROR([MIG not found but required for $host hosts])
+fi
+host_makefile_frag=${srcdir}/../config/i386/i386gnu.mh
+if test ! -f ${host_makefile_frag}; then
+   AC_MSG_ERROR("*** Gdb does not support native target ${host}")
+fi
+frags="$frags $host_makefile_frag"
+;;
+  *)
+host_makefile_frag=/dev/null
+;;
+esac
+
+AC_SUBST_FILE(host_makefile_frag)
+AC_SUBST(frags)
+AC_SUBST(GDBSERVER_HURD)
+
 AC_SUBST(GDBSERVER_DEPFILES)
 AC_SUBST(GDBSERVER_LIBS)
 AC_SUBST(srv_xmlbuiltin)
diff -

[PATCH 0/2] Re-open ethernet device on error

[rekado]

Hi,

this improves on my previous patch.  Before a new master_device port
is created the old port is deallocated to prevent a port leak.  None
of this happens when master_file (naming the device node) is
undefined.

This patch has been tested on Debian GNU/Hurd.  With this patch,
killing netdde no longer takes down pfinet.  Upon encountering a
transmission error, pfinet tries to re-open the ethernet device once
(handled by devnode) and will resend the buffer.


rekado (2):
  Try to re-open network device on transmission error
  Look up device file name on device_open

 devnode/devnode.c | 10 ++
 pfinet/ethernet.c | 17 +++--
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.8.3.1

[PATCH 1/2] Try to re-open network device on transmission error

[rekado]

---
 pfinet/ethernet.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/pfinet/ethernet.c b/pfinet/ethernet.c
index b96c09a..f9fadf1 100644
--- a/pfinet/ethernet.c
+++ b/pfinet/ethernet.c
@@ -241,11 +241,24 @@ ethernet_open (struct device *dev)
 int
 ethernet_xmit (struct sk_buff *skb, struct device *dev)
 {
-  error_t err;
+  error_t err = 0;
   struct ether_device *edev = (struct ether_device *) dev->priv;
   u_int count;
+  short retries = 1;
+
+  do
+{
+  if (err && retries)
+{
+  edev->ether_port = MACH_PORT_NULL;
+  ethernet_open (dev);
+  retries--;
+}
+
+  err = device_write (edev->ether_port, D_NOWAIT, 0, skb->data, skb->len, 
&count);
+}
+  while (err && retries);
 
-  err = device_write (edev->ether_port, D_NOWAIT, 0, skb->data, skb->len, 
&count);
   assert_perror (err);
   assert (count == skb->len);
   dev_kfree_skb (skb);
-- 
1.8.3.1

[PATCH 2/2] Look up device file name on device_open

[rekado]

A fresh `master_device' port is now obtained when accessing the device
file, not only on translator startup.  This ensures that the device
can be re-opened after netdde has died.
---
 devnode/devnode.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/devnode/devnode.c b/devnode/devnode.c
index 50011aa..218b308 100644
--- a/devnode/devnode.c
+++ b/devnode/devnode.c
@@ -164,6 +164,16 @@ ds_device_open (mach_port_t master_port, mach_port_t 
reply_port,
   || device_name == NULL) 
   return D_NO_SUCH_DEVICE;
 
+  if (master_file != NULL)
+{
+  if (master_device != MACH_PORT_NULL)
+mach_port_deallocate (mach_task_self (), master_device);
+
+  master_device = file_name_lookup (master_file, 0, 0);
+  if (master_device == MACH_PORT_NULL)
+error (1, errno, "file_name_lookup");
+}
+
   err = device_open (master_device, mode, device_name, device); 
   *devicetype = MACH_MSG_TYPE_MOVE_SEND;
   return err;
-- 
1.8.3.1

Re: Hacking gnumach to track parental relationship of tasks

[Samuel Thibault]

Richard Braun, le Thu 12 Sep 2013 01:57:10 +0200, a écrit :
> On Mon, Sep 09, 2013 at 09:45:18AM +0200, Samuel Thibault wrote:
> > Ludovic Courtès, le Sat 07 Sep 2013 22:04:06 +0200, a écrit :
> > > However, wouldn’t it be preferable to fix it by interposing on
> > > ‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done with
> > > by setting the TASK_KERNEL_PORT of a task.)
> > 
> > Apparently task_create is a kernel trap.
> 
> How come it appears in the output of rpctrace then ?

As I said, glibc probably nicely uses the RPC instead of the trap.

Samuel