> You have sent this non-RFC intentionally conflicting with [0] to provide > 'alternatives' that is not what a [PATCH] submission is. > > In any case, speculative changes like this should ABSOLUTELY be sent RFC, > and sending things that are merge conflicts as ordinary patches is actually > bordering on being a little rude! > > I'm sure it's unintentional :) but for the sake of us being able to work > with these properly you should just send one as RFC and ask whether it'd be > appropriate to send an alternative, and just allude to it in the one you do > send. > > [0]:https://lore.kernel.org/all/20240925081628.408-1-ebpqwerty472123@xxxxxxxxx/ I am very sorry that I sent the wrong subject which should add "RFC", due to lack of experience. > It's a bit weird to send 'alternatives' - you should by now have a good > sense of which ought to work, if not perhaps more research is required on > your part? I think both solutions can work, and the preliminary discussion is on the mail list for [1] (as this issue is related to security before it was fixed, the discussion is on security@xxxxxxxxxx). The choice depends only on taste. Link: https://lore.kernel.org/all/20240919080905.4506-2-paul@xxxxxxxxxxxxxx/ [1]
