Thread (37 messages) flat view 37 messages, 3 authors, 2020-07-22

Re: [PATCH 06/24] md: open code vfs_stat in md_setup_drive

From: Christoph Hellwig <hch@lst.de>
Date: 2020-07-22 14:05:32
Also in: linux-fsdevel, linux-raid, lkml

On Wed, Jul 22, 2020 at 08:44:32AM +0100, Al Viro wrote:
On Tue, Jul 21, 2020 at 08:27:01PM +0200, Christoph Hellwig wrote:
quoted
On Tue, Jul 21, 2020 at 05:55:39PM +0100, Al Viro wrote:
quoted
How about fs/for_init.c and putting the damn helpers there?  With
calling conventions as close to syscalls as possible, and a fat
comment regarding their intended use being _ONLY_ the setup
in should-have-been-done-in-userland parts of init?
Where do you want the prototypes to go?  Also do you want devtmpfs
use the same helpers, which then't can't be marked __init (mount,
chdir, chroot), or separate copies?
Hmm...  mount still can be __init (devtmpfs_mount() is), and I suspect
devtmpfs_setup() could also be made such - just turn devtmpfsd()
into
static int __init devtmpfsd(void *p)
{
        int err = devtmpfs_setup(p);

	if (!err)
		devtmpfsd_real();	/* never returns */
	return err;
}
and you are done.
Yes, that seems to work.  We can obviously call non-__init functions
from __init ones, and kthread_run doesn't seem to care if it gets passed
a __init function.

Here is what I have now:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/init_path
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help