Re: GSOC Guidance

Hi! Thanks for your interest on GNU/Hurd! On Sun, Dec 1, 2013 at 5:21 AM, Subhashish Pradhan wrote: > > Hello! > > I am Subhashish Pradhan and I am interested in working on the Hurd Project. > > I noticed that you were a GSOC student for GNU/Hurd. So may I contact you > here for any queries tha

[PATCH 6/7] pfinet: improve the pfinet_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 7/7] pflocal: improve the demuxer functions

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 1/7] libdiskfs: improve the diskfs_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 5/7] proc: improve the message_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 4/7] exec: improve the exec_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 2/7] libnetfs: improve the netfs_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

[PATCH 3/7] libtrivfs: improve the trivfs_demuxer function

Handle multiple request types as recommended by the Mach Server Writer's Guide section 4, subsection "Handling Multiple Request Types". This avoids initializing the reply message in every X_server function. The reply message has already been properly initialized in libports, so there is no need t

Re: [PATCH 31/68] ipc/ipc_kmsg.c: remove forward declarations

On 29.11.2013 22:53:56, Marin Ramesa wrote: > * ipc/ipc_kmsg.c (copyinmap, copyoutmap, ipc_msg_print): Remove > forward declarations. > * ipc/ipc_kmsg.h (ipc_msg_print): Add prototype. I just noticed this, the prototype for ipc_msg_print() is a duplicate - it's already declared in ipc/icp_print.h

[PATCH 2/2] Add ifndefs

* i386/i386at/cram.h [_CRAM_H_]: Add ifndef. * i386/i386at/disk.h [_DISK_H_]: Likewise. * i386/i386at/i8250.h [_I8250_H_]: Likewise. * i386/include/mach/i386/asm.h [_MACH_I386_ASM_H_]: Likewise. * i386/include/mach/i386/disk.h [_MACH_I386_DISK_H_]: Likewise. --- i386/i386at/cram.h| 4

[PATCH 1/2] Add comments after endifs

* ddb/db_run.c [FIXUP_PC_AFTER_BREAK]: Add comment after endif. * device/cons.c [MACH_KMSG]: Likewise. [CONSBUFSIZE > 0]: Likewise. * i386/i386/trap.c [MACH_KDB]: Likewise. [MACH_PV_PAGETABLES]: Likewise. * i386/i386at/kd.c [ENABLE_IMMEDIATE_CONSOLE]: Likewise. * ipc/ipc_kmsg_queue.h [_IPC_KMSG_QUE