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

On July 26, 2020 11:24:25 PM PDT, Christoph Hellwig [off-list ref] wrote:

On Sun, Jul 26, 2020 at 11:20:41PM -0700, hpa@zytor.com wrote:

quoted

On July 26, 2020 8:05:34 PM PDT, Al Viro [off-list ref]

wrote:

quoted

quoted

On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote:

quoted

Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to

work,

quoted

quoted

but

quoted

instead open a struct file for /dev/console and then install it as

FD

quoted

quoted

quoted

0/1/2 manually.

I really hate that one.  Every time we exposed the internal details

to

quoted

quoted

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

quoted

quoted

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.