On 3/17/26 5:56 PM, Alexandre Courbot wrote: > On Wed Mar 18, 2026 at 12:34 AM JST, Danilo Krummrich wrote: >> On Tue Mar 17, 2026 at 4:22 PM CET, Alexandre Courbot wrote: >>> On Tue Mar 17, 2026 at 10:53 PM JST, Danilo Krummrich wrote: >>>> On Tue Mar 17, 2026 at 2:20 PM CET, Alexandre Courbot wrote: >>>>> On Tue Mar 17, 2026 at 6:23 PM JST, Cheng-Yang Chou wrote: .... >>>>> That `drm/nova-drm` reads a bit awkwardly to me and feels unnecessary. >>>>> Even `tegra-drm` is in `drm/tegra`. >>>> >>>> Well, that's why I named it "nova" in the first place, but I don't want >>>> KBUILD_MODNAME to diverge from the directory name and I also don't want the >>>> driver name to diverge from KBUILD_MODNAME. >>> >>> What is the rationale for that? I like consistency too, but also think >>> it is not particularly difficult to figure out that "nova-drm" resides >>> in "drm/nova". >> >> It is consistency. But why are we discussing this, what is the concern being >> consistent here? > > I just find the repetition of "drm" unnecessary. That's not a big deal > though and I can definitely live with it.
As I mentioned in an earlier version of this patchset, things such as lsmod(1) do not show the source code directory of one's kernel module. $ lsmod|grep nova nova 16384 0 nova_core 253952 0 And of course, lsmod(1) is not the only case where this comes up: few people know the source directory paths! Nor should they. But this means that in many situations, we are left with an initial report that only includes the module's basename. We would like some hint about what "nova" means, especially given the presence of nova_core. So it turns out that a little redundancy, and even saying something more than once, is helpful in this particular case. :) thanks, -- John Hubbard
