Received-SPF: pass (google.com: domain of linux-kernel+bounces-141593-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
IronPort-PHdr: A9a23:rVPPcBKK4aIq3MRqstmcua0yDhhOgF28FhQe5pxijKpBbeH5uZ/jJ
 0fYo/5qiQyBUYba7qdcgvHN++D7WGMG6Iqcqn1KbpFWVhEEhMlX1wwtCcKIEwv6edbhbjcxG
 4JJU1o2t2qjPx1tEd3lL0bXvmX06DcTHhvlMg8gKu3zG4PWkM2f3OGp8JqVaAJN13KxZLpoJ
 0CupB7K/okO1JFvKKs61lPFo2AdfeNQyCIgKQeYng334YG7+5sLzg==
IronPort-Data: A9a23:hAYFY68t+PX1ubd87wReDrUDgX+TJUtcMsCJ2f8bNWPcYEJGY0x3z
 GseCz2Ha/eIamTyKtB1bI7i/RgP75+BnYVlQFY4pC1EQiMRo6IpJzg2wmQcns+2BpeeJK6yx
 5xGMrEsFOhtEzmB4E7rauC4xZVF/fngbqLmD+LZMTxGSwZhSSMw4TpugOdRbrRA2bBVOCvT/
 4utyyHjEAX9gWIsbjtNs/nrRC5H5ZwehhtJ5jTSWtgT1LPuvyF9JI4SI6i3M0z5TuF8dsamR
 /zOxa2O5WjQ+REgELuNyt4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5nXBYoUnq7vh3S9zxHJ
 HqhgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/wmWeG0YAzcmCA2k7D6044cpqH11N1
 s0jEjwQcQuN2bmflefTpulE3qzPLeHxN48Z/3pn1zycUbAtQIvIROPB4towMDUY358VW62BI
 ZtCL2MyMXwsYDUXUrsTIJ43mualgmb2WzZZs1mS46Ew5gA/ySQrjOiwb4CLK4ziqcN9gWOjm
 kP/+VTCPToqc/W62CGj+Gylr7qa9c/8cMdIfFGizdZugVuO1ikQBQcQWF+Tv/a0kAi9VshZJ
 khS/TAhxYA29Uq2XpzxWBaQvnGJpFgfVsBWHul87xuCooLQ4gCEFi0HRCNAbNAOqsA7X3op2
 0WPktevAiZg2IB5UlqH/buS6Di1IyVQcSkJZDQPSk0O5NyLTJwPsy8jh+1LScadptb0Ajr3h
 TuNqUADa3871KbnC43TEYj7vg+R
IronPort-HdrOrdr: A9a23:Z83XeK0d1R1bCec+77g2nQqjBcBxeYIsimQD101hICG9Lfbo9P
 xGzc566farslcssSkb6KG90cm7LU819fZOkPAs1S/LZnimhILaFvAT0WKE+UyhJ8SezJ8S6U
 4ESdkdNDSeNykGsS+X2njeLz9k+qj4zEnKv5ac854Od3AXV0gI1W4QYWjrdzwTeOAFP+tHKH
 P23Ls+m9PUQwVsUi3NPAh/YwGsnaysqHvOW291OzcXrCO1oXeD7rn8HxKE3hEYfQ9u7N4Zm1
 TtokjS3Inml+u05CP9+gbogqi+nuGP9vJzQOi3zuQFIDTljQilIK57XaeZgTwzqOazrH43jd
 jluX4bToFOwkKUWlvwjQrm2gHm3jprwWTl00WkjXzqptG8bC4mCvBGmZlSfnLimg4dVZBHoe
 V2NlCixsNq5CD77XzADh/zJkpXf3+P0DwfeCgo/iZiuMUlGeJsRMckjTBo+d87bVfHAcYcYa
 tT5AW23ocITbtcBEqp4lVH0ZiiWG8+EQyBRVVHssuJ0yJOlHQ81EcAwtcD901wua7VZqM0rN
 gsCJ4Y3o1mX4sTd+ZwFe0BScy4BijERg/NKnubJRDiGLscM3zAppbr6PFtjdvaN6Ag3d83gt
 DMQVlYvWk9dwbnDtCPxoRC9lTITH+mVTrgx8lC79xyu6H6RrDsLSqfIWpe3/eIsrEaGInWSv
 yzMJVZD7vqKnbvA59A20nkV5xbORAlIYUoUxYAKhuzS+7wW/vXX7bgAYLuzZLWYEEZZl8=
From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Nicolas Schier <nicolas@fjasle.eu>
CC: Nicolas Schier <n.schier@avm.de>,
        "Valerii Chernous -X (vchernou -
 GLOBALLOGIC INC at Cisco)" <vchernou@cisco.com>,
        Masahiro Yamada
	<masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
        Jonathan
 Corbet <corbet@lwn.net>,
        "linux-kbuild@vger.kernel.org"
	<linux-kbuild@vger.kernel.org>,
        "linux-doc@vger.kernel.org"
	<linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] Add MO(mod objs) variable to process ext modules with
 subdirs
Thread-Topic: [PATCH v3] Add MO(mod objs) variable to process ext modules with
 subdirs
Thread-Index: AQHajDWPNw0w9AAG+kK+xjeBwf3pzA==
Date: Thu, 11 Apr 2024 20:50:10 +0000
Message-ID: <ZhhNAQtV3StbaA4z@goliath>
References: <20240405165610.1537698-1-vchernou@cisco.com>
 <ZhfLrGrED-ls6i5V@buildd.core.avm.de> <ZhgdjpE+yl3IYSzl@goliath>
 <Zhg5L2xO_lT4lLwp@fjasle.eu>
In-Reply-To: <Zhg5L2xO_lT4lLwp@fjasle.eu>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?GL9ZhypGj6V8keMO7MCOPFitegp1Z8LIViGdgr6PBxwIU+lYXWlQbtMNhgxd?=
 =?us-ascii?Q?RzMnoO16S58LYj4RmmkBAGfPGX0cvv3Gc+Zxcd5VWMwivR7OGrJnnIJhpjoP?=
 =?us-ascii?Q?lOQUTv0Qu0chAlZ4VK3meeKOsVd5d+yu8bF0zp0UQFp/tkf6UOY3AXuGdy0m?=
 =?us-ascii?Q?iyzYb3J6oIrU/xM51SO1uC6GWBXcAN6Wr3NDNR8fbwc5leIIv6DkSY+2Rg7J?=
 =?us-ascii?Q?KboXYnBbOvy0gO/OGTkFapeq73S0FpC9yRWlNE/+SGtcvIEN9ApmDAgVfiEO?=
 =?us-ascii?Q?rdlfPABYsK3gNMUT64BdUf/c87BALFf7SdFfHy+6+sSE3R9qQDUILnEKpdCH?=
 =?us-ascii?Q?cBFzeJF10+/dv5JiFnKYYtC4Oq4tLRDB2D26otsjWG0KUAmtli7PDp9rzvG/?=
 =?us-ascii?Q?VrWyaspn47sos9xt8grfQEnrN42jeJIwlkYaxxuQfB1bbTYWTwlZWYT9TwsN?=
 =?us-ascii?Q?UI+5nwfx164zSayI5Vywyv7lb1pdj5+mnnXqXGF9I3A/fvX2fMU962jp7L/n?=
 =?us-ascii?Q?4KZec0NKEWGsdrlrV766CAKV1nnfW3ybcU0dapkj+2qrDOCZbCQSM9Q8JT+g?=
 =?us-ascii?Q?Rxd/GjSTyWVixxXimyFjxdCLpZcAeKSV1bD5OCW9IlutBzA6+gzep7NTszlZ?=
 =?us-ascii?Q?fDh9zFzXxXNYrpT7LbEQzyy7T09P4aeMqz+rKXrHVpbZC+KH9+zlyU0CqlLK?=
 =?us-ascii?Q?LPQgaKkD+RoLEesqXcO4VCXLo46tSS7q9R3mxm9Pw5Ud1xp/9GWd+KzU4agX?=
 =?us-ascii?Q?7PbPctSwA9JrvwJwlmjVK/1fUvLH/xGAC7TnhmVOrRu5NqEYUuWc5Gpt7/LB?=
 =?us-ascii?Q?v6NTGug7uKS3q4g3DGw+E7tyyEhKg5KyYO/w4lEQOjVmq96ugysBDm2sIBYI?=
 =?us-ascii?Q?pkiffXB/ePgP9zpWFreCM07tBLeftw01lPkNYJgwXCwH82W39Qgr4kye+QJa?=
 =?us-ascii?Q?PBCPtqSlAzeE7iC4WM4RvocbyEfMsS0GA3UCF7BVClHyRx2nCCeHVLbo8tAU?=
 =?us-ascii?Q?aS8tX7bXVDbe9mDGvsW6XTzxoqngbjQI9n+sGi6SmvUWhk7v94S+lE3Djkv1?=
 =?us-ascii?Q?zqjf+E2vEaTU+FRaH0XCDX3amRw7nmRd7eLAps42yTT9i9t+kgXMPAuYMQBR?=
 =?us-ascii?Q?aIqtwjDDZWPiV1jKBF77C/NRNOF44ycuElJ9vQt8AfGX6My0IVY4WDi1HENQ?=
 =?us-ascii?Q?xl4nwfTZUXcEVTQxs3kJLpNQtZ2KT/4wljkK5g8cdNeZTMtqt3G0SlhRUqy/?=
 =?us-ascii?Q?I1ND5qfKHqVtAwMqAj6RivbRQmvy4U2wnFZVG5+MWQo5PPPOctpi3ttZ9wU4?=
 =?us-ascii?Q?bKOny2SAKO3gC49YkiVRifkmFu3mufPAzhnza4BkVU5oN8LVXU3yno5GEM03?=
 =?us-ascii?Q?ZiHuJmux5Gf6WJvl0ozyFUT7+6Q/5O6jQv8ZH3tkjbvdgUVcIA0cg/d7Y/mS?=
 =?us-ascii?Q?trIw/VFiFW90N65QUb03eyZQa3U1EIo4sdsnpcNaiXffWDjjGRRMRpDsMbe8?=
 =?us-ascii?Q?ncFWleQGufRBhagheg7rSEjMDSPM862msdH3dus+Jj3iKIJZSxyRqLG0KFr7?=
 =?us-ascii?Q?0cm1xGx3+k6uyEmCF2+f3tDrmuOX55QQUzUCmigUHg23ZLCiQOn1PvLxCEej?=
 =?us-ascii?Q?Lw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EEFFCE411ECB6A4C95B20C89C9C0B45B@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5790.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00b69a47-698b-44f6-7794-08dc5a68fa3b
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2024 20:50:10.0490
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: luyQLWHg0w/4OMPiMbTk5m1yJ4BeJIKmCuqpx3mINmqzIjSRwcBgcbvPRELGeR0r9vBjPB9YkuaAT92NWc0M7Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7033
X-Outbound-SMTP-Client: 72.163.7.163, rcdn-opgw-2.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com

On Thu, Apr 11, 2024 at 09:25:35PM +0200, Nicolas Schier wrote:
> On Thu, Apr 11, 2024 at 05:27:42PM +0000 Daniel Walker (danielwa) wrote:
> > On Thu, Apr 11, 2024 at 01:38:20PM +0200, Nicolas Schier wrote:
> > > Hi Valerii,
> > >=20
> > > thanks for your patch.  I know several non-upstream kernel developers
> > > that would like to see support for out-of-source builds of external
> > > kmods (and we developed several work-arounds at AVM as well); but ple=
ase
> > > be aware that patches that don't fix or enhance the in-tree kernel/km=
od
> > > build but only add feature for out-of-tree stuff, are rarely accepted=
.
>=20
> "out-of-tree stuff" was meant to be "out-of-tree kernel modules".  "Rarel=
y" was
> chosen in explicit contrast to "never", but to hint on my personal expect=
ation
> regarding the probability of acceptance.
>=20
> > If that were true we would not have driver/uio/ for example. It seems l=
ike
> > Cisco and NVM should work together produce a solution.
> >=20
> > You could run into this issue even with entirely in tree modules. For e=
xample,
> > we may have a v6.6 kernel but we need some modules from v5.15 for some =
incompatibility
> > reason in v6.6. Then we may build the v5.15 modules as out of tree modu=
les
> > against the v6.6 kernel.
=20
All problems should be fixed or worked around. One bit of code maybe isn't
the best choice or maybe another is, but not fixing or working around the
problem is not really an option.

> If your in-tree module in question does compile and run properly in v5.15=
 and
> in v6.6: why don't you just compile it in-tree in v6.6?  Which driver/mod=
ule do
> you refer to?

I believe it was this driver drivers/crypto/marvell/octeontx2 . I don't rec=
all
every aspect of the issues but it has to do with what Marvell supported in =
their
SDK and the exact hardware we were using and the bootloader we had on the
product.

> > You also have just normal developers making kernel modules which always=
 start as
> > out of tree modules before they are upstreamed. Those modules could be =
any level
> > of complexity.
>=20
> I do not agree, but there is no need to convince me as I am not in the po=
sition
> to decide between acceptance or denial.  I just thought it might be fair =
to
> warn that I do not expect acceptance.

I think it's incorrect, unhealthy even, to look at it that way. If your usi=
ng
Linux to make a product and you have an issue, it should be consider as a r=
eal
issue. Not something maintainer can just discard. Unless the maintainer has
a suggestion to do what is needed or different code to do it.

Daniel=