From: Trevor Lee <begleybrothers@gmail.com>
To: guix-devel@gnu.org
Subject: Replacing Yocto with Guix kernel image builds: best practices
Date: Sun, 17 May 2020 21:41:00 +1000 [thread overview]
Message-ID: <CAJsH2Qm88r9_pu-YLA9hmWb+NjtovHpnS_PDxGoUi=zu67s4Yw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]
Hi,
We are now looking to build Linux kernels using Guix instead of Yocto. We
can't see any reason why the builds wouldn't be linux-libre. Ideally we'd
like our effort to be accepted by upstream guix.
However, being new to Guix we are still coming grips with the best
practice(s) for what we would like to do.
We've looked at Guix's linux.scm, and
Efraim Flashner's post[1] is our primary reference - many thanks Efraim.
We'd appreciate any pointers to package definition(s) that demonstrate best
practices to do what we'd like:
- We'd like to build custom configured kernels for each patch series in the
LTS 4.14.72+, 4.19+ and 5.4+.
- Currently we have two `base` kernel configs that each 'variant'
configuration is applied to for each of a machine 'type' (3 machine types)
and one of two 'arch'.
- Currently we can generate a full kernel `.config` for a
kernel+base+variant+arch (we are working on the best way to handle
different machines if we are not using Yocto.)
- We'd ideally like to generate `vmlinux`, `initrd` and `rootfs` images for
each.
Based on Efraim's post we think the first example is the least friction -
"including an actual .config file as a native input to our custom kernel".
Assume we resolve the machine definition issue. However we're puzzled
about how to best distribute the configuration file such that a build of
kernel x.y.z can be updated with fixes.
The constraint of users being able to use the std guix commands rather than
telling them to download a config file or clone a git repo and copy a
config file is what is puzzling. Some options we thought about seem
inelegant - hence too embarassing to mention - so we'll skip them ;)
Leaving....
1) We did wonder if channels[2] were the way to go with each kernel x.y.z
in its own branch and config files therein. Could anyone point us to
packages that setup and use package specific channels?
2) Should we be aiming to provide a single package with multiple parameters
or is it better to provide a package for each kernel x.y.z, or some other
partitioning. We'd likely want to script the package definition then -
correct?
Appreciate any comments suggestions or tips.
[1]:
https://guix.gnu.org/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/
[2]: https://guix.gnu.org/manual/en/guix.html#Channels
--
Kind Regards
Begley Brothers Inc.
1. *The content of this email is confidential and intended for the
recipient specified in message only. It is strictly forbidden to share any
part of this message with any third party, without a written consent of the
sender. If you received this message by mistake, please reply to this
message and follow with its deletion, so that we can ensure such a mistake
does not occur in the future.*
2. *This message has been sent as a part of discussion between Begley
Brothers Inc. and the addressee whose name is specified above. Should you
receive this message by mistake, we would be most grateful if you informed
us that the message has been sent to you. In this case, we also ask that
you delete this message from your mailbox, and do not forward it or any
part of it to anyone else. Thank you for your cooperation and
understanding.*
3. *Begley Brothers Inc. puts the security of the client at a high
priority. Therefore, we have put efforts into ensuring that the message is
error and virus-free. Unfortunately, full security of the email cannot be
ensured as, despite our efforts, the data included in emails could be
infected, intercepted, or corrupted. Therefore, the recipient should check
the email for threats with proper software, as the sender does not accept
liability for any damage inflicted by viewing the content of this email.*
4. *The views and opinions included in this email belong to their author
and do not necessarily mirror the views and opinions of the company. Our
employees are obliged not to make any defamatory clauses, infringe, or
authorize infringement of any legal right. Therefore, the company will not
take any liability for such statements included in emails. In case of any
damages or other liabilities arising, employees are fully responsible for
the content of their emails.*
[-- Attachment #2: Type: text/html, Size: 5107 bytes --]
next reply other threads:[~2020-05-17 12:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-17 11:41 Trevor Lee [this message]
2020-05-17 13:08 ` [offtopic] Funny footer (was: Replacing Yocto with Guix kernel image builds: best practices) Dmitry Alexandrov
2020-05-17 16:59 ` Josh Marshall
2020-05-17 21:03 ` Trevor Lee
2020-05-17 13:20 ` Replacing Yocto with Guix kernel image builds: best practices Efraim Flashner
2020-05-17 21:23 ` Begley Brothers Inc
2020-05-18 6:35 ` Efraim Flashner
2020-05-19 6:28 ` Begley Brothers Inc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJsH2Qm88r9_pu-YLA9hmWb+NjtovHpnS_PDxGoUi=zu67s4Yw@mail.gmail.com' \
--to=begleybrothers@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.