bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kernel command line


From: Roland McGrath
Subject: Re: kernel command line
Date: Sat, 5 May 2001 20:22:42 -0400 (EDT)

> 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.

I don't recall ever having noticed the host_get_boot_info interface.
That certainly seems like a natural thing to use.

> Anyway, direct Mach access is not preferred anyway, it would be good to have
> it in the Hurd layer.  It almost is since Roland implemented to pass the
> MULTIBOOT_CMDLINE environment variable in kern/bootstrap.c.

Indeed.  The cheesiest thing would be:
        echo "$MULTIBOOT_CMDLINE" > /var/run/kernel-cmdline
in rc.  But that sucks for a r/o filesystem.  

The simplest kludge is to just use "ps --fmt=%command 2" or the libps
equivalent thereof.  PID 2 is always the kernel task, and the existing init
hack diddles things so that the kernel command line appears like a normal
process's command line for the PID 2 pseudo-process.

> 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?

This could be done.  But there is no particular reason to use one
bootstrapping hack instead of another.  The only reason options flow
through the bootstrap filesystem is because of pragmatic necessity.  In the
abstract, we'd like to consider /hurd/init to be the first system server.

> This would actually make it possible to pass the kernel command line down to
> init.  init does currently pass this to proc for the command line to appear
> in the output of ps etc.  Is this interface sufficient, or should proc
> provide the kernel command line directly via an RPC similar to
> host_get_boot_info?

Eh, I don't think it matters.  I don't think "multiboot command line" is
such a wondrous thing to immortalize in a supposedly generic protocol that
things would actually use.  

> Is my analysis somewhere wrong? 
> We should add kernel-command-line to the default boot script.

I think you have accurate described the situation.  But I see no reason
bother with a boot-script hack.  We already have a hack that makes the info
available to init and rc.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]