They are used interchangeably and it doesn't matter too much. You can
always do "p (error_t)rc" in gdb. The reason a few things like
get_privileged_ports might have been written with kern_return_t instead of
error_t was that they were theoretically Mach interfaces that would exist
on a non-Hurd
Hi,
in glibc:/hurd/privports.c:
kern_return_t
__get_privileged_ports (host_priv_t *host_priv_ptr,
device_t *device_master_ptr)
{
if (! _hurd_host_priv)
{
error_t err;
...
Shouldn't this return error_t rather than kern_return_t? As far as I can
see, the kern_
Neal H Walfield <[EMAIL PROTECTED]> writes:
> I have a patch ready to go that changes all int -> int32 and off_t and
> ssize_t to int64. Do you want this. Would you like something else?
No, I think this is the sort of thing we do when we are preparing to
start work on the 2.0 version.
__
On Fri, May 04, 2001 at 10:26:18PM +0200, Marcus Brinkmann wrote:
> This can be pasted into the bootscript via ${kernel-command-line}, and
> passed to init via -K. I think it can be passed to init by adding this to
> --bootflags of the root filesystem. Can someone confirm this?
>
> /hurd/ext2fs.
Hi,
I was wondering about host_get_boot_info and if it could be used to provide
/proc/cmdline in Neals procfs. I don't know about any standard interface to
get a kernel command line.
Well, Mach simply returns an empty string on that call (see kern/machine.c).
I don't know if it should return th
