Re: Is deallocating MACH_PORT_NULL an error ?

On Thu, Jan 22, 2015 at 10:22:04PM +0100, Justus Winter wrote: > So do we consider {deallocating,destroying,mod_refing} MACH_PORT_NULL > or MACH_PORT_DEAD an error, or an expensive nop ? Personally, I'd consider this a nop, like free(NULL) is. -- Richard Braun

Re: Is deallocating MACH_PORT_NULL an error ?

Quoting Samuel Thibault (2015-01-22 22:37:49) > Justus Winter, le Thu 22 Jan 2015 22:22:04 +0100, a écrit : > > So do we consider {deallocating,destroying,mod_refing} MACH_PORT_NULL > > or MACH_PORT_DEAD an error, or an expensive nop ? > > AIUI frobbing PORT_DEAD is quite common indeed, like somet

Re: HURD and a Laptop

On Thu, Jan 22, 2015 at 06:34:44PM +0100, Samuel Thibault wrote: > There are wireless tools on debian-ports. I don't know the details. I guess they are about 10 years old by now. Even back then, they did not work very well, as I recall. Michael

Re: [PATCH gnumach] ipc: warn about more port management bugs

Justus Winter, le Thu 22 Jan 2015 22:22:05 +0100, a écrit : > + if (MACH_PORT_VALID (name) && space == current_space()) { > printf("task %.*s destroying an invalid port %lu, most > probably a bug.\n", sizeof current_task()->name, current_task()->name, name); I'm

Re: Is deallocating MACH_PORT_NULL an error ?

Justus Winter, le Thu 22 Jan 2015 22:22:04 +0100, a écrit : > So do we consider {deallocating,destroying,mod_refing} MACH_PORT_NULL > or MACH_PORT_DEAD an error, or an expensive nop ? AIUI frobbing PORT_DEAD is quite common indeed, like something died while doing something, and we ended up with a

Is deallocating MACH_PORT_NULL an error ?

Hello :) I've been hunting port handling bugs, and came up with the patch that will follow this mail. You will note that we do not print warnings if MACH_PORT_NULL or MACH_PORT_DEAD is supplied: runsystem@nonmonolithic / > (mach-port-deallocate mach-task-self MACH_PORT_NULL) Error: (mach-port-de

[PATCH gnumach] ipc: warn about more port management bugs

* ipc/mach_port.c (mach_port_destroy): Simplify expression. (mach_port_deallocate): Likewise. (mach_port_mod_refs): Also warn about errors when using this function. --- ipc/mach_port.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/ipc/mach_port.c b/ipc/mach

Re: HURD and a Laptop

Riccardo Mottola, le Thu 22 Jan 2015 18:07:29 +0100, a écrit : > Samuel Thibault wrote: > >Riccardo Mottola, le Thu 22 Jan 2015 17:19:15 +0100, a écrit : > >>>I already installed HURD, booted and tried to ifconfig /dev/eth0 but that > >>>doesn't work with the server dying. I suppose the device is n

Re: HURD and a Laptop

Hi Samuel, Samuel Thibault wrote: Riccardo Mottola, le Thu 22 Jan 2015 17:19:15 +0100, a écrit : >I already installed HURD, booted and tried to ifconfig /dev/eth0 but that >doesn't work with the server dying. I suppose the device is not there. Our netdde translator doesn't have support for PCM

Re: HURD and a Laptop

Riccardo Mottola, le Thu 22 Jan 2015 17:19:15 +0100, a écrit : > I already installed HURD, booted and tried to ifconfig /dev/eth0 but that > doesn't work with the server dying. I suppose the device is not there. Our netdde translator doesn't have support for PCMCIA cards. We have PCMCIA drivers i

Re: HURD and a Laptop

On Thu, 2015-01-22 at 17:19 +0100, Riccardo Mottola wrote: > Hi, ... > I already installed HURD, booted and tried to ifconfig /dev/eth0 but > that doesn't work with the server dying. I suppose the device is not there. Install inetutils-tools to check out: inetutils-ifconfig -l /dev/eth0 lo

HURD and a Laptop

Hi, since I have so many troubles getting Hurd running on my ol' and faithful computer again, with my GRUB problems being the nastiest one, I thought of an alternative strategy. It is most probably realy a GRUB problem, but at the end it affects my ability to run HURD again. Being no fun of

Re: [PATCH hurd 0/6] Add file record locking support

On Thu, 2015-01-08 at 16:54 +0100, Samuel Thibault wrote: > Which wouldn't be a good thing, as I said it's better to split the > changes where it can be, to make bisecting easier. > > > To be a little more constructive: Is this patch order correct? > > 1) libfshelp_rlock.patch: implement fshelp_r

[PATCH 3/6] libtrivfs_file_record_lock

libtrivfs/ChangeLog 2001-04-11 Neal H Walfield * file-record-lock.c: New file. Implement netfs_S_file_record_lock. * Makefile (SRCS): Add file-record-lock.c --- libtrivfs/Makefile | 2 +- libtrivfs/file-record-lock.c | 27 +++ 2 files

[PATCH 5/6] hurd_add_RPC

hurd/ChangeLog 2014-08-21 Svante Signell * fs.defs: Added description. * hurd_types.defs: Make struct flock_t seven integers long since l_start and l_len are 64bit. * hurd_types.h: typedef flock_t as flock64. 2001-04-10 Neal H Walfield * fs.defs: Ne

[PATCH 1/6] libfshelp_rlock

libfshelp/ChangeLog 2014-08-21 Svante Signell * Makefile: Link with pthread * define temporary CPP_FLAGS until glibc is updated * rlock-drop-peropen.c: Port from cthreads to libpthread. * rlock-tweak.c: Likewise * fshelp.h: Likewise * rlock.h: Like

[PATCH 4/6] libnetfs_file_record_lock

libnetfs/ChangeLog 2001-04-11 Neal H Walfield * file-record-lock.c: New file. Implement netfs_S_file_record_lock. * Makefile (SRCS): Add file-record-lock.c --- libnetfs/Makefile | 5 ++--- libnetfs/file-record-lock.c | 30 ++ 2 fi

[PATCH 6/6] libfshelp-tests_rlock

./ChangeLog 2014-08-21 Svante Signell * Makefile: Add sub-directory libfshelp-tests. libfshelp-tests/ChangeLog 2014-08-21 Svante Signell * Makefile: Link with pthread, add build of checklock * define temporary CPP_FLAGS until glibc is updated * checklock.c: Ne

[PATCH 2/6] libdiskfs_file_record_lock

libdiskfs/ChangeLog 2014-08-21 Svante Signell * define temporary CPP_FLAGS until glibc is updated * file-lock-stat.c: Port from cthreads to libpthread. * file-lock.c: Likewise * file-record-lock: Likewise 2001-04-11 Neal H Walfield * Makefile (FSSRCS)