From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90373C433E0 for ; Wed, 17 Mar 2021 14:25:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47B4864F4D for ; Wed, 17 Mar 2021 14:25:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231237AbhCQOYc (ORCPT ); Wed, 17 Mar 2021 10:24:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231396AbhCQOY2 (ORCPT ); Wed, 17 Mar 2021 10:24:28 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BE0BC06174A for ; Wed, 17 Mar 2021 07:24:27 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lMX5q-00HNpD-U3; Wed, 17 Mar 2021 15:24:15 +0100 Message-ID: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> Subject: Re: [RFC v8 00/20] Unifying LKL into UML From: Johannes Berg To: Octavian Purdila Cc: Hajime Tazaki , linux-um , jdike@addtoit.com, Richard Weinberger , Anton Ivanov , linux-kernel-library , linux-arch , Akira Moroo Date: Wed, 17 Mar 2021 15:24:14 +0100 In-Reply-To: (sfid-20210317_150351_779146_168D64BD) References: (sfid-20210317_150351_779146_168D64BD) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Hi, > One use case where this matters are non OS environments such as > bootloaders [1], running on bare-bone hardware or kernel drivers [2, > 3]. IMO it would be nice to keep these properties. OK, that makes sense. Still, it seems it could be a compile-time decision, and doesn't necessarily mean LKL has to be NOMMU, just that it could support both? I'm really trying to see if we can't get UML to be a user of LKL. IMHO that would be good for the code, and even be good for LKL since then it's maintained as part of UML as well, not "just" as its own use case. > > If your abstraction was instead "switch context" then you could still > > implement it using pthreads+mutexes, or you could implement it using > > fibers on windows, or posix contexts - but you'd have a significantly > > reduced API surface, since you'd only expose __switch_to() or similar, > > and maybe a new stack allocation etc. > > You are right. When I started the implementation for ucontext it was > obvious that it would be much simpler to have abstractions closer to > what Linux has (alloc, free and switch threads). But I never got to > finish that and then things went into a different direction. OK, sounds like you came to the same conclusion, more or less. > > Additionally, I do wonder how UML does this now, it *does* use setjmp, > > so are you saying it doesn't properly use the kernel stacks? > > > > To clarify a bit the statement in the paper, the context there was > that we should push the thread implementation to the > application/environment we run rather than providing "LKL" threads. > This was particularly important for running LKL in other OSes kernel > drivers. But you are right, we can use the switch abstraction and > implement it with threads and mutexes for those environments where it > helps. Right - like I pointed to USFSTL framework, you could have posix ucontext, fiber and pthread at least, and obviously other things in other environments (ThreadX anyone? ;-) ) > > But conceptually, why wouldn't it be possible to have a liblinux.so that > > *does* build with MMU and userspace support, and UML is a wrapper around > > it? > > > > This is an interesting idea. Conceptually I think it is possible. > There are lots of details to be figured out before we do this. I think > that having a NOMMU version could be a good step in the right > direction, especially since I think a liblinux.so has more NOMMU > usecases than MMU usecases - but I haven't given too much thought to > the MMU usecases. Yeah, maybe UML would be the primary use case. I have been thinking that there would be cases where you could combine kunit and having userspace though, or unit-style testing but not with kunit which is "inside" the kernel, but instead having the test code more "outside" the test kernel. That's all kind of handwaving though and not really that crystallized in my mind. That said, I'm not entirely sure NOMMU would be the right path towards this - if we do want to go this route it'll probably need changes in both LKL and UML to converge to this point, and at least build it into the abstractions. For example the "idle" abstraction discussed elsewhere (is it part of the app or part of the kernel?), or the thread discussion above (it is part of the app but how is it implemented?) etc. johannes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2] helo=sipsolutions.net) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMX5w-003Fkq-NY for linux-um@lists.infradead.org; Wed, 17 Mar 2021 14:24:22 +0000 Message-ID: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> Subject: Re: [RFC v8 00/20] Unifying LKL into UML From: Johannes Berg Date: Wed, 17 Mar 2021 15:24:14 +0100 In-Reply-To: (sfid-20210317_150351_779146_168D64BD) References: (sfid-20210317_150351_779146_168D64BD) MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Octavian Purdila Cc: Hajime Tazaki , linux-um , jdike@addtoit.com, Richard Weinberger , Anton Ivanov , linux-kernel-library , linux-arch , Akira Moroo Hi, > One use case where this matters are non OS environments such as > bootloaders [1], running on bare-bone hardware or kernel drivers [2, > 3]. IMO it would be nice to keep these properties. OK, that makes sense. Still, it seems it could be a compile-time decision, and doesn't necessarily mean LKL has to be NOMMU, just that it could support both? I'm really trying to see if we can't get UML to be a user of LKL. IMHO that would be good for the code, and even be good for LKL since then it's maintained as part of UML as well, not "just" as its own use case. > > If your abstraction was instead "switch context" then you could still > > implement it using pthreads+mutexes, or you could implement it using > > fibers on windows, or posix contexts - but you'd have a significantly > > reduced API surface, since you'd only expose __switch_to() or similar, > > and maybe a new stack allocation etc. > > You are right. When I started the implementation for ucontext it was > obvious that it would be much simpler to have abstractions closer to > what Linux has (alloc, free and switch threads). But I never got to > finish that and then things went into a different direction. OK, sounds like you came to the same conclusion, more or less. > > Additionally, I do wonder how UML does this now, it *does* use setjmp, > > so are you saying it doesn't properly use the kernel stacks? > > > > To clarify a bit the statement in the paper, the context there was > that we should push the thread implementation to the > application/environment we run rather than providing "LKL" threads. > This was particularly important for running LKL in other OSes kernel > drivers. But you are right, we can use the switch abstraction and > implement it with threads and mutexes for those environments where it > helps. Right - like I pointed to USFSTL framework, you could have posix ucontext, fiber and pthread at least, and obviously other things in other environments (ThreadX anyone? ;-) ) > > But conceptually, why wouldn't it be possible to have a liblinux.so that > > *does* build with MMU and userspace support, and UML is a wrapper around > > it? > > > > This is an interesting idea. Conceptually I think it is possible. > There are lots of details to be figured out before we do this. I think > that having a NOMMU version could be a good step in the right > direction, especially since I think a liblinux.so has more NOMMU > usecases than MMU usecases - but I haven't given too much thought to > the MMU usecases. Yeah, maybe UML would be the primary use case. I have been thinking that there would be cases where you could combine kunit and having userspace though, or unit-style testing but not with kunit which is "inside" the kernel, but instead having the test code more "outside" the test kernel. That's all kind of handwaving though and not really that crystallized in my mind. That said, I'm not entirely sure NOMMU would be the right path towards this - if we do want to go this route it'll probably need changes in both LKL and UML to converge to this point, and at least build it into the abstractions. For example the "idle" abstraction discussed elsewhere (is it part of the app or part of the kernel?), or the thread discussion above (it is part of the app but how is it implemented?) etc. johannes _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um