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

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

[Tomko]

Hi everyone,

Do anyone know why it need to open("/dev/console"....) at the end of the 
init() before calling execve("/sbin/init") ? Why open this for the in , 
out , err channel at this moment but not open it at the time when going 
to use , e.g. open it in the shell .

Regards,
TOM

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

[Bodo Eggert]

Tomko <tomko@avantwave.com> wrote:

> Do anyone know why it need to open("/dev/console"....) at the end of the
> init() before calling execve("/sbin/init") ? Why open this for the in ,
> out , err channel at this moment but not open it at the time when going
> to use , e.g. open it in the shell .

How is the shell supposed to know which files to open, or if it's supposed
to open files at all?
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

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

[Richard B. Johnson]

On Fri, 3 Jun 2005, Tomko wrote:

> Hi everyone,
>
> Do anyone know why it need to open("/dev/console"....) at the end of the
> init() before calling execve("/sbin/init") ? Why open this for the in ,
> out , err channel at this moment but not open it at the time when going
> to use , e.g. open it in the shell .
>
> Regards,
> TOM

For error messages (as well as it's the law)! Init needs a terminal.
Init is the 'father' of all future tasks and they need a default terminal
too.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

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

[Wakko Warner]

Richard B. Johnson wrote:
> For error messages (as well as it's the law)! Init needs a terminal.
> Init is the 'father' of all future tasks and they need a default terminal
> too.

Is it at all possible that if /dev/console does not exist that the kernel
can mknod it?

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

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

[Richard B. Johnson]

On Fri, 3 Jun 2005, Wakko Warner wrote:

> Richard B. Johnson wrote:
>> For error messages (as well as it's the law)! Init needs a terminal.
>> Init is the 'father' of all future tasks and they need a default terminal
>> too.
>
> 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
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).

> 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

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

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

[Wakko Warner]

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

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

[J. Scott Kasten]

Wakko Warner wrote:

>J. Scott Kasten wrote:
>  
>
>>Wakko Warner wrote:
>>    
>>
>>>Is it at all possible that if /dev/console does not exist that the kernel
>>>can mknod it?
>>>      
>>>
>>Yes, you could modify the kernel source to create the directory and 
>>device nodes for you if you must.  I have written a few embedded drivers 
>>that created their access nodes that way.
>>    
>>
>
>That's interesting.  All I wanted to do was create /dev and /dev/console if
>they don't exist.  The project I was working on was a 2 stage where stage 1
>loads stage 2 (stage 1 is small enough for floppy use).  Since space is a
>concern, I was wondering if the entries in a cpio archive would be more or
>less bytes compared to the code in the kernel to do it.  At the moment I
>have a vanilla kernel that I'm using (2.6.12-rc5).
>  
>
Have you considered making a root cramfs?  I could almost guarantee that 
it would be smaller, not only that, but you get a gzip like compression 
for free.  Now that I have a little better picture of what you are 
trying to do, I would suggest using a read-only cramfs for your root 
file system.  You can selectively mount writeable file systems over it.

In fact, at the end of your "boot strapping process", you could 
pivot_root/chroot into a live file system on disk then drop the cramfs.  
I use this procedure on the flash of my Zaurus.  It boots a cramfs image 
from the on-board flash which then loads the SD card driver, checks some 
things out, and finally mounts and chroots into a 512MB flash card with 
a nearly stock debian image on ext2.

Actually, even debian uses this type of procedure to fsck the disks and 
look for new devices before turning control over to the disk based system.

>  
>
>>You can also modify the arch/xxx/startup.c file and change the inital 
>>console to /dev/null or just NULL if you need too.  However, I will warn 
>>you of some bad experiences.  I found that tar, and the bash shell 
>>sometimes misbehave with no terminal.  They would inexplicably hang 
>>unless I forced I/O paths 0, 1, 2 to /dev/null.  Tar and the shell would 
>>hang, even though they were not prompting, nor expecting input.  Yet I 
>>could set the initial console to a serial port and it would run fine, 
>>even if the command generated no output!  Very strange and hard to debug 
>>in a restricted environment like that.  Somewhere in that code, it must 
>>have been testing the default I/O paths to see if they were tty like 
>>devices or something and then freaking out with unexpected results.
>>    
>>
>
>The system will be used by console users only (mostly me), thus I can't use
>/dev/null.  The / is populated via a gzipped cpio archive passed via initrd. 
>I don't care if it's right, all that matters is that it works and is small.
>
>  
>
>>My best advice in a situation like this is to actually write your own 
>>pseudo console device driver.  It's not that hard and you might actually 
>>find a way to make it usefull for debugging.  Basicly make it a console 
>>that feeds about a 2K static ring buffer in kernel memory.  That gets 
>>you a few screen fulls of data for debugging.  If you have a PC style 
>>real-time clock, there is a 2K static ram in most of those.  Or "ping" 
>>it out through the network with magic ICMP packets.  Either way, you 
>>have created a usefull debugging tool that will be invaluable for 
>>resolving bootstrapping problems, and you just won't have to deal with 
>>the strangeness I mentioned above.
>>    
>>
>
>I don't believe I can do this.  I've never written a kernel driver before. 
>What I built was a short lived system.  As I stated, it has to be small
>(stage 1 only).  I can now easily reproduce the building of the kernel and
>stage 1 and fit it on a floppy (that was when I upgraded from rc4 to rc5). 
>I had originaly had ext2 compiled in, since 1) the old initrd ramdisk image
>was ext2 2) it was the only filesystem I was using that had unix file
>permissions (and was writable) 3) it was actually the smallest compared to
>the other ones I used.  Now that I pass cpio archive to it, I no longer need
>ext2 compiled in (it's on stage 2 which is either cdrom or usb disk)
>  
>
I don't think you need to do all that I suggested earlier.  I cam in on 
the middle of this discussion and it sounded like a small embedded 
environment you were trying to enhance.  The cramfs image thing I 
described above is probably a much better fit for your needs.