> From: Michael Kelley <[email protected]>
> Sent: Wednesday, May 27, 2026 8:05 AM
> > >
> > > Function and structure names in the Hyper-V DRM driver currently
> > > use "hyperv_" as the prefix. This conflicts with usage in core Hyper-V
> > > and VMBus code, and incorrectly implies that functions and structures
> > > in this driver apply generically to Hyper-V. A specific conflict arises
> > > for "hyperv_init", which is an initcall for generic Hyper-V
> > > initialization on arm64. The conflict prevents the use of
> > > initcall_blacklist on the kernel boot line to skip loading this driver.

I also hit the issue. Thanks for the fix!

> > > Fix this by substituting "hvdrm_" as the prefix for all functions and
> >
> > I would personally prefer "hv_drm_", since it seems clearer.
> 
> My choice of "hvdrm" mimics the old Hyper-V FBdev driver, which
> uses "hvfb" as the prefix. However, looking through everything that
> starts with "hv" in /proc/kallsyms, I also see prefixes with the additional
> underscore.  "hv_kbd_" in the Hyper-V keyboard driver is an example.
> The Hyper-V utils drivers have both forms -- I see "hv_vss_", "hv_ptp_",
> and "hv_kvp_", but also "hvt" (for Hyper-V Transport). So the historical
> practice is inconsistent.
> 
> I'm OK going either way.  Does anyone else want to express a
> preference?

I also prefer "hv_drm_". 

> > > -struct hyperv_drm_device {
> > > +struct hvdrm_drm_device {
> >
> > "hvdrm_drm_device" looks kinda redundant, perhaps
> > s/hyperv_drm_device/hv_drm_device would be more sensible.

s/hyperv_drm_device/hv_drm_dev/ seems better to me.

 
> Yes, I'll make this change. And in looking through kallsyms, I
> see that the Hyper-V DRM driver has "hv_fops", which did not
> get changed in the mechanical substitution because it doesn't
> start with "hyperv_".  I'll change it to hv_drm_fops.
> 
> Michael

Some comments need to be updated accordingly, e.g.
/* hvdrm_drm_modeset */
/* hvdrm_drm_proto */

This needs to be updated as well:
+static const struct drm_encoder_funcs hvdrm_drm_simple_encoder_funcs_cleanup

Thanks,
Dexuan

Reply via email to