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,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 6F1C134C45; Thu, 18 Aug 2022 09:15:50 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 0774134BFE; Thu, 18 Aug 2022 09:15:47 +0000 (UTC) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by atuin.qyliss.net (Postfix) with ESMTPS id 9796834BFB for ; Thu, 18 Aug 2022 09:15:42 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id z2so1101442edc.1 for ; Thu, 18 Aug 2022 02:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=H2hFcAFePNc7+pvnmr0F85+L1u5OW9lzLxcjurik+zs=; b=D8js5VlqwNPaCUuHDEKQxaLMR+GL2R0BGJMfoKRMI7cZKkXLKQRKyS+QrbNRQOnBiK UAszyZhfzIgtmJW5TduXJ7/x+OA5zMkQx50aK6W1QrWJx8X7r0ZOzvMO4N7pizvzgR0w /Zsfchq6EqIgMUf9RXuakXNxszEb+kUkoJagBK3G/4/WMf6uId+aj+9+63ZKICRljVBd 4zUjWt3jJ/E+V80mFvzX77qe1RvkpLc33bmuuBTN7XAZOthuZwxsTSbr4moX6pIMZ0u7 FpXT/dTMOcCXxCHx8weJRgRZ8e44WH1z60ww4t3MB+b9edDfJRBNJSNY5/Q2e+6//PgK QUnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=H2hFcAFePNc7+pvnmr0F85+L1u5OW9lzLxcjurik+zs=; b=Y2oLah5rdgz/UI8f27e3ltR5cu3orSk48+aPwt9fucluLzeowMzoUoDyB95cIgyub0 AlAuQxg1bPzbp335JlLfjxc/2Vv8BjNuAmfR2KtrsWshicmcXyQBGCUHvKH1X8/ZoFsg ZULGUWziKBsZMW/DPb1XrNlYaS6mBeaBtIRrzEppUcmt5QyBzWk+o5FJVgi3zxES4m90 2/3W+2ZflFtaFUsvuYUOfGcffU7bm4+1Kx5J5JJ8CgSPdWm0LsoDTt2JpTnmMMUnTJkc AIRxw4fjsDW8LjNUL+QWIqbvu22+w3Ig5zkXGqBhUHPqKDPY0W9LSHbsQuliKmVUoo/1 ymKw== X-Gm-Message-State: ACgBeo3sgqEkLJxl11EV7uIpxDay7Fo8k2uW4MOBOP4X1mqT5XGOv8q6 4O0dDdH7brw8Jq+Ag7CwIAhH4uUFUZG1uwPkXW67/B+/PWBAyg== X-Google-Smtp-Source: AA6agR5z1ZcX91sSdPEmRkRZj1S2TWQT82FQhdBni/p4etYNAzpM6pxenINUyN2JrAq0AmZV1zqm67LZMapZFkpwQvI= X-Received: by 2002:a05:6402:2949:b0:445:dc8d:44d with SMTP id ed9-20020a056402294900b00445dc8d044dmr1570868edb.60.1660814140168; Thu, 18 Aug 2022 02:15:40 -0700 (PDT) MIME-Version: 1.0 References: <20220817075255.wjw24mzuyyl3lhgz@eve> <20220817133935.js4f6ypqrgsov7m5@eve> In-Reply-To: <20220817133935.js4f6ypqrgsov7m5@eve> From: Ville Ilvonen Date: Thu, 18 Aug 2022 12:15:28 +0300 Message-ID: Subject: Re: HW identification and configuration on Spectrum To: Alyssa Ross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: NQ55TAZSR4BRWBM2FZISBJGUADXHC7QZ X-Message-ID-Hash: NQ55TAZSR4BRWBM2FZISBJGUADXHC7QZ 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 Wed, Aug 17, 2022 at 4:39 PM Alyssa Ross wrote: > Yeah, I agree something like this would be good. Especially when > testing on hardware as you say. I would like to think more about > exactly how this should work. Do you think that, if you it were > possible to develop Spectrum on Spectrum, it would be acceptable to have > to reboot into a new configuration if the host system was changed? > (Assume that the process of actually building the new system is fast =E2= =80=94 > the reboot would be the main overhead.) Option to develop on the target system is something people (not vocal here) already expect. I think booting into a new configuration is MCU style development process and not a fast enough iteration cycle on Linux user space in all scenarios. Even in kernel driver development, one may want to unload/load module during development but even disable module loading as a security hardening mechanism in deployment/production configuration. Another example is security policies development (SELinux) - you want to iterate and test them in user space during development but you want to deploy them immutable. Then again, kernel or device tree changes will require rebooting. Point is - rebooting for everything is not development friendly enough mechanism alone. > You mean set it to your own, custom version of nixos-hardware that > included WIP support for the board you were working on? Yeah, that Yeah, like an own git repo as source for nix-channel to pick the nix-hardware module. Ideally, some of that could be easily contributed to nix-hardware upstream - currently it seems to accept different quality support for different HW so that should not be an issue. > wouldn't be a problem at all. Sounds good. > > > In the medium term, I'd like to decouple nixos-hardware's custom kern= el > > > packages from NixOS configurations. But that would require somebody > > > finding the time to sit down and make the change, and also convince > > > other nixos-hardware users that it's the way to go. I don't think it > > > would be a problem though, especially if it meant nixos-hardware gett= ing > > > more active maintenance, which it's lacking at the moment because it'= s > > > not too well advertised and so not enough people are using it. > > > > Ideally yes and I hope we could contribute to that effort. However, we = need > > to focus on getting Spectrum running on aarch64 with imx8 for now. For = that > > I'm reading that nixos-hardware approach is preferred. > > Yeah, it's definitely the way to go. And if we can make nixos-hardware > better in future, that would just be further progress on top of > integrating nixos-hardware as described above. Right. Even iMX8 dev board generic support might be interesting for other projects. I've seen iMX8M EVK being used at least with Zircon on Fuchsia. Best, -Ville