From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8408038FA6; Sat, 14 Jun 2025 19:46:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749930412; cv=none; b=dhvn61w/K66VhXU4YWA1KkjFBsTLfEvGZy6teWnXy0piTojwQbHYa4GAqvsOwa8fVW/xef5StpUQlzzGtzgV57Yxra/Kww55YFZ4tPWPELSxZs/ivPfZoFb6Uqehgm3XmxLhYHlzdhbRjt15tFSOsKEPxIbCOhEr/wL94piOows= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749930412; c=relaxed/simple; bh=QB5PhTxl2zxZGW2hQuAMgRZkgYvJOmtHRS8o1u5BWwc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LSjg4VptIoAcbhO+AFL33BUlzcpSoU9U6c5gfldwI8vtk7jfJjZC8LLlIm/npiAWuOIfLLm0Tv2uSxGthPGGABKIVWAnBMSkejw0kv8jtKyNBwxUSjcxCZLkve3Njf4vkDIiBKOERD5juuTIjyrjWhIKARA5XO+dY5otMBB8Zvw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fnofkYhe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fnofkYhe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33770C4CEEB; Sat, 14 Jun 2025 19:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749930411; bh=QB5PhTxl2zxZGW2hQuAMgRZkgYvJOmtHRS8o1u5BWwc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fnofkYhecJv5nZ7IAdQ1eBNk0HN3PmuuLgwecprmbz/pHzTdSWqrYZG3ommQjPbuw jcc8P1tjWSWTbXRl4POwEwlIWJ1mIxugLF5CdsTmYJZRPfaYhZawI5mfpuM5d8VX8J YR7jUFPeoWgdh4m1JtKuJAuZhUZG5gMs9hv7zDn6URlGQ4N6qGiSa82f/R3OevuDnS GEZMZVjIvNjnE5ZqCN4w2mXTqbqhm1UKqji7auA4yJlvRkBw5gkmKepDn6SuVwlJ8y GgA70nsn4DXsH9OyeHbK3UW/M/gIedXyQT+ZMhbcMMd+AxF8Fmha5PfZSH8IsPdmRP rI8qd0Qw3cPHg== Date: Sat, 14 Jun 2025 12:46:49 -0700 From: Jakub Kicinski To: Mauro Carvalho Chehab Cc: Donald Hunter , Jonathan Corbet , Linux Doc Mailing List , Akira Yokosawa , Breno Leitao , "David S. Miller" , Eric Dumazet , Ignacio Encinas Rubio , Jan Stancek , Marco Elver , Paolo Abeni , Ruben Wauters , Shuah Khan , joel@joelfernandes.org, linux-kernel-mentees@lists.linux.dev, linux-kernel@vger.kernel.org, lkmm@lists.linux.dev, netdev@vger.kernel.org, peterz@infradead.org, stern@rowland.harvard.edu Subject: Re: [PATCH v4 12/14] MAINTAINERS: add maintainers for netlink_yml_parser.py Message-ID: <20250614124649.2c41407c@kernel.org> In-Reply-To: <20250614205609.50e7c3ad@foz.lan> References: <20250614173235.7374027a@foz.lan> <20250614103700.0be60115@kernel.org> <20250614205609.50e7c3ad@foz.lan> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 14 Jun 2025 20:56:09 +0200 Mauro Carvalho Chehab wrote: > > I understand that from the PoV of ease of maintenance of the docs. > > Is it fair to say there is a trade off here between ease of maintenance > > for docs maintainers and encouraging people to integrate with kernel > > docs in novel ways? > > Placing elsewhere won't make much difference from doc maintainers and > developers. I must be missing your point. Clearly it makes a difference to Donald, who is a maintainer of the docs in question. > I'm more interested on having a single place where python libraries > could be placed. Me too, especially for selftests. But it's not clear to me that scripts/ is the right location. I thought purely user space code should live in tools/ and bulk of YNL is for user space. > Eventually, some classes might be re-used in the future > by multiple scripts and subsystems, when it makes sense, just like we do > already with Kernel's kAPIs. This also helps when checking what is the > Python's minimal version that are required by the Kernel when updating > it at: I think this is exactly the same point Donald is making, but from YNL perspective. The hope is to share more code between the ReST generator, the existing C generator and Python library. The later two are already based on a shared spec model.