Hi,
Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and
reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root.
To summarize, pivot_root has been a life saver as the earlier real_root_dev
might not have been useful in this case.
Not using the ramfs limits for now, will do soon.
Thanks
Amit
Werner Almesberger wrote:
> Amit D Chaudhary wrote:
>
>> what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
>> since the root is now the "new" root, dev/console will be used automatically?
>
>
> No, you would continue using the file descriptors which are already
> open, i.e. on /dev/console on the old root.
>
>
>> Also, why chroot, why not call init directly?
>
>
> To make sure the root of the current process is indeed changed.
> pivot_root currently forces a chroot on all processes (except the
> ones that have explicitly moved out of /) in order to move all the
> kernel threads too, but this is not a nice solution. Once a better
> solution is implemented for the kernel threads, we might drop the
> forced chroot, and then the explicit chroot here becomes important.
>
>
>> Since the above never returns, what follows in not freed.
>
>
> You can run them later, e.g. /etc/rc.d/rc.local
> Or, if you needs the space immediately, make "what-follows" a
> script than first frees them, and then exec's init.
>
> - Werner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
