Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
Documentation/features/vm/pte_special/arch-support.txt
between commit:
2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")
from the jc_docs tree and commit:
1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
from the akpm-current tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
BTW, it would be nice if the the question "Why was this file removed?" was
answered by that jc_docs commit message ... I actually wonder if this
file needs to return (I have no way of knowing).
--
Cheers,
Stephen Rothwell
On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> Documentation/features/vm/pte_special/arch-support.txt
>
> between commit:
>
> 2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")
>
> from the jc_docs tree and commit:
>
> 1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
>
> from the akpm-current tree.
>
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
>
> BTW, it would be nice if the the question "Why was this file removed?" was
> answered by that jc_docs commit message ... I actually wonder if this
> file needs to return (I have no way of knowing).
My bad; thanks for pointing this out.
Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
I defer to your (community) decision regarding "if this file needs to return"
(Cc-ing Ingo, who created the file and also suggested its removal); I remain
available for preparing the patch to restore (and refresh) this file, should
you agree with this approach.
Andrea
>
> --
> Cheers,
> Stephen Rothwell
Really Cc-ing Ingo:
On Wed, May 09, 2018 at 03:28:24PM +0200, Andrea Parri wrote:
> On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> > Documentation/features/vm/pte_special/arch-support.txt
> >
> > between commit:
> >
> > 2bef69a385b4 ("Documentation/features/vm: Remove arch support status file for 'pte_special'")
> >
> > from the jc_docs tree and commit:
> >
> > 1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
> >
> > from the akpm-current tree.
> >
> > I fixed it up (the former removed the file, so I did that) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> >
> > BTW, it would be nice if the the question "Why was this file removed?" was
> > answered by that jc_docs commit message ... I actually wonder if this
> > file needs to return (I have no way of knowing).
>
> My bad; thanks for pointing this out.
>
> Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
>
> I defer to your (community) decision regarding "if this file needs to return"
> (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> available for preparing the patch to restore (and refresh) this file, should
> you agree with this approach.
>
> Andrea
>
>
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
On Wed, 9 May 2018 15:28:24 +0200
Andrea Parri <[email protected]> wrote:
> > BTW, it would be nice if the the question "Why was this file removed?" was
> > answered by that jc_docs commit message ... I actually wonder if this
> > file needs to return (I have no way of knowing).
>
> My bad; thanks for pointing this out.
>
> Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
>
> I defer to your (community) decision regarding "if this file needs to return"
> (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> available for preparing the patch to restore (and refresh) this file, should
> you agree with this approach.
So I'll confess that I balked on the lack of a changelog, but then decided
to proceed with the patch (and the other removal as well) due to the lack
of the Kconfig option.
Now that I look a little closer, I think the real issue is that the
"features" documentation assumes that there's a Kconfig option for each,
but there isn't in this case. The lack of a Kconfig option does not,
this time around, imply that the feature has gone away.
I think that I should probably revert this patch in the short term.
Longer-term, it would be good to have an alternative syntax for "variable
set in the arch headers" to describe situations like this.
Make sense?
Thanks,
jon
On Wed, May 09, 2018 at 08:59:20AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 15:28:24 +0200
> Andrea Parri <[email protected]> wrote:
>
> > > BTW, it would be nice if the the question "Why was this file removed?" was
> > > answered by that jc_docs commit message ... I actually wonder if this
> > > file needs to return (I have no way of knowing).
> >
> > My bad; thanks for pointing this out.
> >
> > Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
> >
> > I defer to your (community) decision regarding "if this file needs to return"
> > (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> > available for preparing the patch to restore (and refresh) this file, should
> > you agree with this approach.
>
> So I'll confess that I balked on the lack of a changelog, but then decided
> to proceed with the patch (and the other removal as well) due to the lack
> of the Kconfig option.
>
> Now that I look a little closer, I think the real issue is that the
> "features" documentation assumes that there's a Kconfig option for each,
> but there isn't in this case. The lack of a Kconfig option does not,
> this time around, imply that the feature has gone away.
>
> I think that I should probably revert this patch in the short term.
> Longer-term, it would be good to have an alternative syntax for "variable
> set in the arch headers" to describe situations like this.
Both matters were discussed during v1:
http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com
... (and the glory details are documented in features-refresh.sh ;-) ).
As I suggested above, simply reverting this patch will leave this file,
(and only this file!) out-of-date (and won't resolve the conflict with
Laurent's patch ...).
Andrea
>
> Make sense?
>
> Thanks,
>
> jon
On Wed, 9 May 2018 18:53:28 +0200
Andrea Parri <[email protected]> wrote:
> > Now that I look a little closer, I think the real issue is that the
> > "features" documentation assumes that there's a Kconfig option for each,
> > but there isn't in this case. The lack of a Kconfig option does not,
> > this time around, imply that the feature has gone away.
> >
> > I think that I should probably revert this patch in the short term.
> > Longer-term, it would be good to have an alternative syntax for "variable
> > set in the arch headers" to describe situations like this.
>
> Both matters were discussed during v1:
>
> http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com
>
> ... (and the glory details are documented in features-refresh.sh ;-) ).
So I'll admit to being confused, since I don't see discussion of the
actual topic at hand.
> As I suggested above, simply reverting this patch will leave this file,
> (and only this file!) out-of-date (and won't resolve the conflict with
> Laurent's patch ...).
Reverting this patch retains the updates from earlier in the series, and
does indeed make the conflict go away, so I'm still confused. What am I
missing?
Thanks,
jon
On Wed, May 09, 2018 at 11:11:36AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 18:53:28 +0200
> Andrea Parri <[email protected]> wrote:
>
> > > Now that I look a little closer, I think the real issue is that the
> > > "features" documentation assumes that there's a Kconfig option for each,
> > > but there isn't in this case. The lack of a Kconfig option does not,
> > > this time around, imply that the feature has gone away.
> > >
> > > I think that I should probably revert this patch in the short term.
> > > Longer-term, it would be good to have an alternative syntax for "variable
> > > set in the arch headers" to describe situations like this.
> >
> > Both matters were discussed during v1:
> >
> > http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.parri@amarulasolutions.com
> >
> > ... (and the glory details are documented in features-refresh.sh ;-) ).
>
> So I'll admit to being confused, since I don't see discussion of the
> actual topic at hand.
A couple of clicks on "next in thread" :-)
https://marc.info/?l=linux-kernel&m=152284705204400&w=2
https://marc.info/?l=linux-kernel&m=152294150600751&w=2
>
> > As I suggested above, simply reverting this patch will leave this file,
> > (and only this file!) out-of-date (and won't resolve the conflict with
> > Laurent's patch ...).
>
> Reverting this patch retains the updates from earlier in the series, and
> does indeed make the conflict go away, so I'm still confused. What am I
> missing?
The updates from earlier added "TODO" rows for nds32 and riscv, but missed
the "TODO -> ok" update for riscv.
Andrea
>
> Thanks,
>
> jon