Re: question why need open /dev/console in init() when starting kernel

[Wakko Warner <wakko@animx.eu.org>]

Richard B. Johnson wrote:
> On Fri, 3 Jun 2005, Wakko Warner wrote:
> >Is it at all possible that if /dev/console does not exist that the kernel
> >can mknod it?
> >
> 
> Yes. Your initial console can be NULL, set as a kernel command-line

I forgot about this.  I was thinking in the cases where it wasn't.

> parameter. You should really be using an initial RAM disk (initrd).
> That gets mounted for boot, containing whatever is necessary to
> properly start the system, then change to the file root (or not).
> This is how hundreds of different embeded systems are started.
> 
> Execute-in-place, which I think you are trying with 'cpio' will
> continue to give you problems because you can't test it except
> by throwing it off-the-cliff to see if it flies. RAM-disk systems
> can be tested, booting on any media (even a floppy).

I built a small system that runs in 2 stages.  stage 1 basically only
searches for stage 2 and can fit on a floppy.  It has a kernel (no
filesystem support builtin) and a cpio archive that is loaded via initrd. 
It has actually decreased the size and since everything runs out of a tmpfs
filesystem anyway, it works just fine.

I was asking a technical question, not a preferred usage question.

I would think that if the kernel itself can populate a tmpfs from a cpio
archive, it can also mknod /dev/console.  However, I don't know if the
code would increase the kernel more than just having 2 extra entries in a
cpio archive.

> >Would the code to do this be larger than 2 entries in a cpio archive (one
> >for /dev directory and one for /dev/console char dev)?

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals