linux-kernel - Re: [PATCH v2 8/8] Documentation: add howto build in macos

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <86cylev7o7.wl-maz@kernel.org>
Date: Sun, 08 Sep 2024 10:03:36 +0100
From: Marc Zyngier <maz@...nel.org>
To: "Daniel Gomez (Samsung)" <d+samsung@...ces.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,	da.gomez@...sung.com,	Nathan
 Chancellor <nathan@...nel.org>,	Nicolas Schier <nicolas@...sle.eu>,	Lucas
 De Marchi <lucas.demarchi@...el.com>,	Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>,	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,	Maxime Ripard
 <mripard@...nel.org>,	Thomas Zimmermann <tzimmermann@...e.de>,	David Airlie
 <airlied@...il.com>,	William Hubbs <w.d.hubbs@...il.com>,	Chris Brannon
 <chris@...-brannons.com>,	Kirk Reiser <kirk@...sers.ca>,	Samuel Thibault
 <samuel.thibault@...-lyon.org>,	Paul Moore <paul@...l-moore.com>,	Stephen
 Smalley <stephen.smalley.work@...il.com>,	Ondrej Mosnacek
 <omosnace@...hat.com>,	Catalin Marinas <catalin.marinas@....com>,	Will
 Deacon <will@...nel.org>,	Oliver Upton <oliver.upton@...ux.dev>,	James
 Morse <james.morse@....com>,	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,	Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>,	Jiri Slaby <jirislaby@...nel.org>,	Nick
 Desaulniers <ndesaulniers@...gle.com>,	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,	Simona Vetter
 <simona.vetter@...ll.ch>,	linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org,	intel-xe@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org,	speakup@...ux-speakup.org,
	selinux@...r.kernel.org,	linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,	linux-serial@...r.kernel.org,	llvm@...ts.linux.dev,
	Finn Behrens <me@...enk.dev>,	gost.dev@...sung.com
Subject: Re: [PATCH v2 8/8] Documentation: add howto build in macos

On Sat, 07 Sep 2024 10:32:20 +0100,
"Daniel Gomez (Samsung)" <d+samsung@...ces.com> wrote:
> 
> On Sat, Sep 7, 2024 at 10:33 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Fri, Sep 6, 2024 at 8:01 PM Daniel Gomez via B4 Relay
> > <devnull+da.gomez.samsung.com@...nel.org> wrote:
> > >
> > > From: Daniel Gomez <da.gomez@...sung.com>
> > >
> > > Add documentation under kbuild/llvm to inform about the experimental
> > > support for building the Linux kernel in macOS hosts environments.
> > >
> > > Signed-off-by: Daniel Gomez <da.gomez@...sung.com>
> >
> >
> > Instead, you can add this instruction to:
> >
> > https://github.com/bee-headers/homebrew-bee-headers/blob/main/README.md
> 
> Sure, that can be done as well. But the effort here is to have this
> integrated. So, I think documentation should be in-tree.

I think this ship sailed the moment you ended-up with an external
dependency.

Having looked at this series (and in particular patch #4 which falls
under my remit), I can't help but think that the whole thing should
simply live as a wrapper around the pristine build system instead of
hacking things inside of it. You already pull external dependencies
(the include files). Just add a script that sets things up
(environment variables that already exist) and calls 'make' in the
kernel tree.

I also dislike that this is forcing "native" developers to cater for
an operating system they are unlikely to have access to. If I break
this hack tomorrow by adding a new dependency that MacOS doesn't
provide, how do I fix it? Should I drop my changes on the floor?

As an alternative, and since you already have to create a special
file-system to contain your kernel tree, you may as well run Linux in
a VM, which I am told works pretty well (QEMU supports HVF, and there
are plenty of corporate-friendly alternatives). This would solve your
problem once and for all.

Please don't take the above the wrong way. I'm sympathetic to what you
are trying to do. But this is IMO going in the wrong direction.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.