From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hajime Tazaki Subject: Re: [RFC v2 05/37] lkl: memory handling Date: Wed, 05 Feb 2020 16:38:22 +0900 Message-ID: References: <8b0c833bde42e761cadfd3542263ad7a8be5eb5b.1573179553.git.thehajime@gmail.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from mail-pf1-f196.google.com ([209.85.210.196]:44468 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727068AbgBEHi2 (ORCPT ); Wed, 5 Feb 2020 02:38:28 -0500 Received: by mail-pf1-f196.google.com with SMTP id y5so740398pfb.11 for ; Tue, 04 Feb 2020 23:38:26 -0800 (PST) In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: richard.weinberger@gmail.com Cc: linux-um@lists.infradead.org, linux-arch@vger.kernel.org, levex@linux.com, tavi.purdila@gmail.com, retrage01@gmail.com, liuyuan@google.com, linux-kernel-library@freelists.org On Tue, 26 Nov 2019 07:10:28 +0900, Richard Weinberger wrote: > > On Fri, Nov 8, 2019 at 6:03 AM Hajime Tazaki wrote: > > > > From: Octavian Purdila > > > > LKL is a non MMU architecture and hence there is not much work left to > > do other than initializing the boot allocator and providing the page > > and page table definitions. > > > > The backstore memory is allocated via a host operation and the memory > > size to be used is specified when the kernel is started, in the > > lkl_start_kernel call. > > > > Signed-off-by: H.K. Jerry Chu > > Signed-off-by: Hajime Tazaki > > Signed-off-by: Levente Kurusa > > Signed-off-by: Yuan Liu > > Signed-off-by: Octavian Purdila > > --- > > arch/um/lkl/include/asm/page.h | 14 ++++++ > > arch/um/lkl/include/asm/pgtable.h | 62 +++++++++++++++++++++++ > > arch/um/lkl/include/uapi/asm/host_ops.h | 5 ++ > > arch/um/lkl/mm/bootmem.c | 66 +++++++++++++++++++++++++ > > This is also something which needs unification with UML. > UML in NOMMU mode would be LKL then... At this moment, I leave those part as is; changing LKL to MMU mode makes less possibility to host various underlying environments (non-Linux hosts, non-x86 subarchs). If you have nice suggestions (such as adding texts to docs), it would be definitely helpful. -- Hajime