Re: [PATCH 18/23] init: open code setting up stdin/stdout/stderr

hpa
2020-07-27T06:36:34Z

On July 26, 2020 11:24:25 PM PDT, Christoph Hellwig <hch@lst.de> wrote:
>On Sun, Jul 26, 2020 at 11:20:41PM -0700, hpa@zytor.com wrote:
>> On July 26, 2020 8:05:34 PM PDT, Al Viro <viro@zeniv.linux.org.uk>
>wrote:
>> >On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote:
>> >> Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to
>work,
>> >but
>> >> instead open a struct file for /dev/console and then install it as
>FD
>> >> 0/1/2 manually.
>> >
>> >I really hate that one. Every time we exposed the internal details
>to
>> >the fucking early init code, we paid for that afterwards. And this
>> >goes over the top wrt the level of details being exposed.
>> >
>> >_IF_ you want to keep that thing, move it to fs/file.c, with dire
>> >comment
>> >re that being very special shite for init and likely cause of
>> >subsequent
>> >trouble whenever anything gets changed, a gnat farts somewhere, etc.
>> >
>> > Do not leave that kind of crap sitting around init/*.c; KERNEL_DS
>> >may be a source of occasional PITA, but here you are trading it for
>a
>> >lot
>> >worse one in the future.
>>
>> Okay... here is a perhaps idiotic idea... even if we don't want to
>run stuff in actual user space, could we map initramfs into user space
>memory before running init (execing init will tear down those mappings
>anyway) so that we don't need KERNEL_DS at least?
>
>Err, why? The changes have been pretty simple, and I'd rather not come
>up with new crazy ways just to make things complicated.

Why? To avoid this neverending avalanche of special interfaces and layering violations. Neatly deals with non-contiguous contents and initramfs in device memory, etc. etc. etc.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.