From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 8EA9B3A59D; Fri, 19 Aug 2022 06:26:32 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 1514D3A5C1; Fri, 19 Aug 2022 06:26:29 +0000 (UTC) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by atuin.qyliss.net (Postfix) with ESMTPS id BD36D3A5BF for ; Fri, 19 Aug 2022 06:26:24 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id v4so3694899ljg.0 for ; Thu, 18 Aug 2022 23:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=qtSFqpklZ1gp/TaFa8f7X1I0CluB9wgqVcEjYHysfbg=; b=Chry6VDUdV6X8ZoLn8nnFaIe24k+xT+ixqiMNlkODNWZsIuDE5IsZGY60HUbOvvm7t WFbmHdLZg0yQioVlhn2dF1z7xpgUIWEit7FoeKjTc2HXmS3QKnmT4cOcHHCpDvaiuT4c 3BRoj1NbjkZX8JRWY9Fult11Po7S0UwLg04ZbJ0B0Lhm3tFK2wjovRSCRAl5uoCStAeF F8hTSOWllRrcrznzXAcz36Eu6kSNe/060maXJ9Mxrnvv00kC3USSt+wN268bAlGxsS8b 7JUlziVonB0CC8fpDxGRyS1rYfVwGc8mKKoYFvMXakhErXFX0VOXOAF6QUBUch9kGj+1 z5cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=qtSFqpklZ1gp/TaFa8f7X1I0CluB9wgqVcEjYHysfbg=; b=rQFjPYhTrfp0/3JdH9YFJmexbCJH48ngm5ZJ5f4dY+o2i5wTZ1yZT/mmDyKdEmtjbz f1qw9U0KXSzO6kCn/ssNF6bWX/7QB6wfC81bpIk/X3xPbWI+AiLNlZimCbsMIB5Sd1vK 7krXOrtsmLMqZ9Fjk73GwQu3mpyh+C+yjjuYEx+EpYEtK5NWahcyXpjgw62fpmlsomr4 S7/KFT59ighZNl61lgWURlp9sfu4iCPtFl+ptXMGSXfsojh81Bc+dEdZrA0XCc16H43/ krU11rv7MQljs51WHDHl5L3aYDE8R6dzQYftGG0NI82WRTZVr0ZH2gNX2MNnwRVZYJH9 ++PQ== X-Gm-Message-State: ACgBeo1yj5REtewmSol4DkQOdynqcR3PAkB2iayL37UuCQVMP2k4ZKUk G1Vtn5O8lnY/4Dr4533cPE2KyQ== X-Google-Smtp-Source: AA6agR7YYZ8iiJnbxq6ouTvT8JtSeAqWyWjtUK0JR2MxZb6isP8K2nwnsyWQZQSmlOzXyrMyezA0BA== X-Received: by 2002:a2e:9348:0:b0:261:890d:b19c with SMTP id m8-20020a2e9348000000b00261890db19cmr1689536ljh.441.1660890382251; Thu, 18 Aug 2022 23:26:22 -0700 (PDT) Received: from [192.168.1.26] (mobile-access-567369-205.dhcp.inet.fi. [86.115.105.205]) by smtp.gmail.com with ESMTPSA id u24-20020ac258d8000000b00492cebbeefbsm11552lfo.59.2022.08.18.23.26.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Aug 2022 23:26:21 -0700 (PDT) Message-ID: <5b6a2db2-78cc-ab4a-257c-6695f56f5cd8@unikie.com> Date: Fri, 19 Aug 2022 09:26:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: Development on the Spectrum host Content-Language: en-US To: Alyssa Ross References: <20220817075255.wjw24mzuyyl3lhgz@eve> <20220817133935.js4f6ypqrgsov7m5@eve> <20220818101713.ls23kzatcfbcbeau@eve> From: Ville Ilvonen In-Reply-To: <20220818101713.ls23kzatcfbcbeau@eve> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: KFOLOUDKNSJJIIKBEENPPVL7HOSQDWH2 X-Message-ID-Hash: KFOLOUDKNSJJIIKBEENPPVL7HOSQDWH2 X-MailFrom: ville.ilvonen@unikie.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-discuss.spectrum-os.org-0; header-match-discuss.spectrum-os.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: discuss@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 18.8.2022 13.17, Alyssa Ross wrote: > Okay. Obviously we can support booting with the filesystem mounted > read-write and no dm-verity. But the problem with that is that then > changes have to be manually copied back to the source tree. We could One way to handle this is so that people git clone to the target and build small incremental changes there. > try to add some conveniences for that (e.g. a facility to diff the > modified root filesystem with the orginal version). It still means > making changes to the compiled system, rather than working on the > source, but for the kind of changes you're talking about, maybe doing > it that way and then integrating the changes into the Spectrum source > at the end wouldn't be too bad? When installation of development tools to the target is limited, remotely mounting filesystem (e.g. sshfs) from the development host works. > Ideally it would be nice to have something like nixos-rebuild switch, > that can build a new system and then switch into it. But the problem > is, you have to figure out how to *automatically* take the runtime state > of the system (the processes and services that are running), and somehow > carry that over into the new system, where anything could have changed. > So I'm not sure how we'd do that. NixOS's implementation of this is > massive, tightly coupled to both NixOS and systemd, and still it's not > very difficult to get it into a weird state where you need to reboot > anyway to get an accurate idea of what the change does (or, if you > don't realise you need to do that, you just think the change hasn't > worked). If a kernel module has changed, do you try to unload an > reload it? That's pretty complicated to implement, because you have to > unbind the devices from it, unload the module, then rebind them, and > even then the module might have had important state that's been lost. Good examples but there's no one answer to these scenarios. Depends really much on the case and developer preferences. Often services restarting is enough, sometimes system reboot is required. Also, people doing kernel development are usually fairly seasoned and consider which makes sense to themselves. E.g. kernel modules run reset for the hardware in init() and scripts/tests can be used to handle unbind-unload-rebind in driver development. Managing state persistence over resets or SW updates is an eternity problem. It's an interesting problem - I studied dynamic software updates and state migration is one key challenge there. DSU has not taken traction, though. It's tough to update both code and the runtime state. We have legacy and culture of restarts. In critical systems it's designed and handled with hardware, even system redundancy - not at single component level. > If the developer is working on that kernel module it's probably okay, > but what if they're working on something else and just pulled a bunch of > changes that happened to include a kernel module change? Same with if > e.g. the Weston service changes, except in that case we have no way to > restore the previous state. So either we choose not to automatically > restart Weston, in which case we're not really running the new system, > but a weird hybrid that may have bugs not present in either the old or > new system, or we do restart Weston, and risk an unsuspecting user > losing their whole windowing session. True. In these scenarios I've learned not to try to cover every possible scenario on behalf of other people. Developers are smart and they understand and learn constraints of system changes. > If there's a way we could make this work well, I'm open to it, but it's > not at all obvious to me what that would look like. Given above, I try to keep this at high level design. Two configurations: a. development - enables development, testing and debugging with caveats b. user - immutable, hardened, strong security promises Now we have b. which makes a. by design impossible *on target*, making development iterations slow. The question is if we want to generally enable a. and then say - "there it is for anyone who needs it". Best, -Ville