Re: A suggestion for `/servers/socket/2'

2007-04-08 Thread Roland McGrath
> Getting `pfinet' to crash can be provoked as easily as setting the system > time while it is running. So far, so good. You've been using the Hurd too long if you call this "so good". ;-) ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.or

A suggestion for `/servers/socket/2'

2007-04-08 Thread Thomas Schwinge
Hello! `/servers/socket/2' has a passive translator setting, which means that the `pfinet' running on that node will be started automatically as the node is accessed -- accessed by using the glibc socket api, for example. This also means that it will automatically be restarted should it have crash

GNU Mach devices: no-sender notifications

2007-04-08 Thread Thomas Schwinge
Hello! I think I don't really undestand the matter of no-sender notifications in the GNU Mach device code. All device glue codes (native Mach, Linux block and net and pcmcia) use the following code sequence to request a no-sender notification: #v+ /* * Request no-senders notifications on de

Re: I/O permission control in OSKit-Mach

2007-04-08 Thread Thomas Schwinge
On Mon, Apr 02, 2007 at 01:26:51PM -0700, Roland McGrath wrote: > The old device_emulation_ops stuff in i386at is similar, > i.e. it provides hooks to implement the device RPCs. But where would be the correct place in GNU Mach to store these ``io_port_t from, to'' values? [OSKit-Mach]/oskit/ds_os

MIG type translation (was: I/O permission bitmap patch for oskit-mach)

2007-04-08 Thread Thomas Schwinge
Hello! On my endavor to understand the MIG magic better, I stumbled over the following: On Fri, Mar 08, 2002 at 01:39:49AM +0100, Marcus Brinkmann wrote: > [...] i386/include/mach/i386/mach_i386.defs > +type io_port_t = MACH_MSG_TYPE_INTEGER_16; > +type io_perm_t = mach_port_t > +