From: Benda Xu <heroxbd@gentoo.org>
To: gentoo-soc@lists.gentoo.org
Subject: [gentoo-soc] kernel ebuild (Was: Application for Google Summer of Code 2018-Mishal Roy)
Date: Fri, 23 Mar 2018 12:33:40 +0900 [thread overview]
Message-ID: <87fu4r8nzf.fsf_-_@gentoo.org> (raw)
In-Reply-To: <CAGfcS_kXHLD5oabGEdjvSV9rxbYeEq4ixbJYj1PcvqqNiGdriQ@mail.gmail.com> (Rich Freeman's message of "Thu, 22 Mar 2018 11:25:49 -0400")
Hi Rich,
Thank you for the input. I had the same puzzle, too.
Rich Freeman <rich0@gentoo.org> writes:
> On Thu, Mar 22, 2018 at 12:07 AM, Benda Xu <heroxbd@gentoo.org> wrote:
>>
>>> builds x86 linux kernel from source code present in /usr/src/linux
>>> directory of Gentoo liveDVD
>>
>> This is not how Gentoo ebuild works, the build should prepare the source
>> code.
>
> I don't want to derail whatever your goals are here, but IMO an ebuild
> that actually builds a kernel would be useful.
>
> However, such an ebuild shouldn't touch /usr/src. If I were doing a
> kernel build ebuild I'd have it fetch kernel sources like any other
> package, then build it in the normal location, with configuration
> options provided via USE flags or some default config, and then
> install the final kernel in /boot.
+1
> I realize that isn't how Gentoo has done it for the last 20 years, but
> I've always thought that it would make sense to have a way to actually
> maintain up-do-date kernels in the same manner as any other package,
> with the /usr/src approach being an also-supported alternative.
It's worth to know why we made such a choice. I took the status quo as
is and have never thought carefully about it.
> That said, there are complications. Some kernel modules want prepared
> (or even built) sources and this approach would clean those after
> install.
We can have a USE flag to control whether the source should be installed
along with the image. And those kernel module can claim their
dependence on the USE flag.
> Also, we'd probably need to use subslots for initramfs rebuilds or
> something like that. I suspect this is why it hasn't been done yet.
@Alice, any hints from the kernel team?
> Again, I don't want to derail SoC with this unless there was an intent
> to actually build a kernel this way...
Well, thank you! That's why I wanted to keep the technical discussions
related to GSOC public. It's always good to have our students to
communicate with and learn from experts of Gentoo. Ultimately, the
projects should be useful to the Gentoo community.
Yours,
Benda
next prev parent reply other threads:[~2018-03-23 3:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 17:51 [gentoo-soc] Application for Google Summer of Code 2018-Mishal Roy Mishal Roy
2018-03-22 4:07 ` Benda Xu
2018-03-22 15:16 ` Mishal Roy
2018-03-23 0:47 ` Benda Xu
2018-03-22 15:25 ` Rich Freeman
2018-03-22 16:06 ` Mishal Roy
2018-03-23 3:33 ` Benda Xu [this message]
2018-03-23 6:50 ` Patrick Lauer
2018-03-23 13:37 ` Rich Freeman
2018-03-23 13:49 ` EBo
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=87fu4r8nzf.fsf_-_@gentoo.org \
--to=heroxbd@gentoo.org \
--cc=gentoo-soc@lists.gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox