Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754988AbbLQX7D (ORCPT ); Thu, 17 Dec 2015 18:59:03 -0500 Received: from mail-yk0-f175.google.com ([209.85.160.175]:36212 "EHLO mail-yk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754195AbbLQX7B (ORCPT ); Thu, 17 Dec 2015 18:59:01 -0500 MIME-Version: 1.0 In-Reply-To: <20151217234625.GM20409@wotan.suse.de> References: <1450217797-19295-1-git-send-email-mcgrof@do-not-panic.com> <56731D32.4040900@zytor.com> <20151217234625.GM20409@wotan.suse.de> From: "Luis R. Rodriguez" Date: Thu, 17 Dec 2015 15:58:41 -0800 X-Google-Sender-Auth: Mizw5oAgUblowUu_rDZ8C9AK2lY Message-ID: Subject: Re: [RFC v1 0/8] x86/init: Linux linker tables To: "H. Peter Anvin" Cc: "Luis R. Rodriguez" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Konrad Rzeszutek Wilk , Rusty Russell , Andy Lutomirski , Boris Ostrovsky , mcb30@ipxe.org, Juergen Gross , Jan Beulich , joro@8bytes.org, Andrey Ryabinin , andreyknvl@google.com, long.wanglong@huawei.com, qiuxishi@huawei.com, aryabinin@virtuozzo.com, Mauro Carvalho Chehab , Valentin Rothberg , Peter Senna Tschudin , X86 ML , Michal Marek , "xen-devel@lists.xensource.com" , Michael Matz , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1560 Lines: 29 On Thu, Dec 17, 2015 at 3:46 PM, Luis R. Rodriguez wrote: > solutions such > as those devised on the IOMMU init stuff do memmove() for sorting depending on > semantics defined (in the simplest case here so far dependency between init > sequences), this makes each set of sequences very subsystem specific I should also note -- since the sort uses memmove() we're constrained to using run time sort only once we can ensure the kernel can do that without issues. I'd hope x86_64_start_reservations() is a safe place, if not please let me know. Likewise, since one prospect here is to bring further strong subarchitecture semantics even earlier (help appreciated), say as early as possible in x86_64_start_kernel(), it'd be nice to know the earliest memmove() is safe there. In this case the solution doesn't yet make use of calls in between x86_64_start_kernel() and x86_64_start_reservations() but if it could (we'd need a way for x86_init_fn_early_init() to access the subarchitecture, help appreciated) we *might* in the future want run time sort this early. It might still be possible to *not* do a run time sort until later so long as the priority level linker sort mechanism suffices for all early init routines. That's another possibility, should memmove() be a problem that early. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/