On Tue, Mar 05, 2024 at 11:51:36AM +0100, Nicolas Schier wrote:
> On Mon, Mar 04, 2024 at 11:45:45AM -0800, Elliott Mitchell wrote:
> > On Mon, Mar 04, 2024 at 10:50:49AM +0100, Nicolas Schier wrote:
> > > On Fri, Mar 01, 2024 at 12:51:01PM -0800, Elliott Mitchell wrote:
> > > > As $(abs_objtree) and $(abs_srctree) already exist, $(abspath )
> > > > shouldn't be used with $(objtree) or $(srctree).
> > > >
> > > > Fixes: 0e1aa629f1ce ("kbuild: Do not clean resolve_btfids if the output does not exist")
> > > > Signed-off-by: Elliott Mitchell <ehem+linux@xxxxxxx>
> > > > ---
> > > > I believe this is pretty much all fixes, but 0e1aa629f1ce was the most
> > > > recent one.
> > >
> > > If you add a 'Fixes' trailer, please just include changes that fix that
> > > commit. You're patch does much more than just modifying the changes
> > > from commit 0e1aa629f1ce.
> >
> > Since all of these should have been used $(abs_srctree) or $(abs_objtree)
> > when committed, all of these are fixes. Issue is most of them moved at
> > least once, so tracking down the list is annoying.
> >
> > You consider ignoring this is fixing around 5-13 commits reasonable?
>
> I think, fixing inconsistencies is a good thing, but I'm afraid it's
> not always important enough to mark such changes as 'Fixes', as 'Fixes'
> is especially used for auto-selecting patches for stable trees.
Eventually resolved to 8 in the end:
Fixes: 606b9ac81a63 ("doc-rst: generic way to build only sphinx sub-folders")
Fixes: 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)")
Fixes: 787360f8c2b8 ("samples: bpf: fix build after move to compiling full libbpf.a")
Fixes: 50d3a3f81689 ("kbuild: Add resolve_btfids clean to root clean target")
Fixes: 0e1aa629f1ce ("kbuild: Do not clean resolve_btfids if the output does not exist")
Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
Fixes: 98d614bdaa58 ("docs: Makefile: use the right path for DOCS_CSS")
Fixes: 6008105b4f4e ("samples/hid: add new hid BPF example")
I guess this isn't too crucial to document, though it is useful to
observe the rate at which these were being added. I consider it within a
maintainer's discretion to pull such from a commit message.
On Tue, Mar 05, 2024 at 11:43:07AM +0100, Nicolas Schier wrote:
> On Mon, Mar 04, 2024 at 11:36:27AM -0800, Elliott Mitchell wrote:
> > On Mon, Mar 04, 2024 at 10:57:18AM +0100, Nicolas Schier wrote:
> > >
> > > can you please describe a concrete problem you want to solve with your
> > > patch set? Masahiro already asked in [1], and I still don't get your
> > > motivation while reading your cover letter. It would be helpful to see
> > > your goal when looking at your patches.
> >
> > I'm trying to develop an alternative kernel build system for one Linux
> > distribution. Due to how other pieces of the distribution work it seems
> > using the out-of-tree build mechanism to build in-tree modules may be a
> > better approach. This may be abusing the current build system, but if it
> > works without breaking anything else that should be acceptable.
>
> oh well. You are probably aware of things like
> subdir-ccflags-y and that kmods built via M= are considered to be
> out-of-tree and taint the kernel.
I hadn't yet been considering such issues since that isn't yet urgent.
In fact given the level of patching this distribution does, having the
kernel marked as tained for out-of-tree modules may well be appropriate.
The amount of backporting is impressive.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sigmsg@xxxxxxx PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
