Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1329497 > unrolled thread

Re: [PATCH v2 00/16] Common Dell SMBIOS API

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 00/16] Common Dell SMBIOS API Lukas Wunner <lukas@wunner.de> - 2016-02-08 20:30 +0100
    Re: [PATCH v2 00/16] Common Dell SMBIOS API Darren Hart <dvhart@infradead.org> - 2016-02-08 21:50 +0100

#1329497 — Re: [PATCH v2 00/16] Common Dell SMBIOS API

Hi,

On Mon, Feb 08, 2016 at 11:20:14AM -0800, Darren Hart wrote:
> My only major concern is module load order dependencies. Inter-module
> dependencies are frowned upon with good reason, the kernel load ordering is
> non-deterministic and it's possible, for example, for dell-laptop to fail to
> find the symbols exported by dell-smbios under certain conditions.
> 
> I have worked around this in the past with things like the following:
> 
> #ifdef MODULE
> #ifdef CONFIG_FOO_MODULE
> 	if (request_module("foo"))
> 		return -ENODEV;
> #endif
> #endif
> 
> Something like the above may be necessary for dell-smbios in dell-laptop,
> dell-wmi, and dell-leds now that they depend on the dell-smbios exported
> functions.
> 
> Cc Greg in case there is a better way to handle this that I'm not aware of.

Deferred probing seems to be the preferred way, see e.g.:
https://lists.freedesktop.org/archives/dri-devel/2016-January/098404.html

(In this example, apple_gmux_present() determines presence of the device
and !vga_switcheroo_handler_flags() determine non-presence of its driver.)

This will also work if the subsystem depended on is compiled in rather
than in a module.

Best regards,

Lukas

[toc] | [next] | [standalone]

#1329548

On Mon, Feb 08, 2016 at 08:30:07PM +0100, Lukas Wunner wrote:
> Hi,
> 
> On Mon, Feb 08, 2016 at 11:20:14AM -0800, Darren Hart wrote:
> > My only major concern is module load order dependencies. Inter-module
> > dependencies are frowned upon with good reason, the kernel load ordering is
> > non-deterministic and it's possible, for example, for dell-laptop to fail to
> > find the symbols exported by dell-smbios under certain conditions.
> > 
> > I have worked around this in the past with things like the following:
> > 
> > #ifdef MODULE
> > #ifdef CONFIG_FOO_MODULE
> > 	if (request_module("foo"))
> > 		return -ENODEV;
> > #endif
> > #endif
> > 
> > Something like the above may be necessary for dell-smbios in dell-laptop,
> > dell-wmi, and dell-leds now that they depend on the dell-smbios exported
> > functions.
> > 
> > Cc Greg in case there is a better way to handle this that I'm not aware of.
> 
> Deferred probing seems to be the preferred way, see e.g.:
> https://lists.freedesktop.org/archives/dri-devel/2016-January/098404.html
> 
> (In this example, apple_gmux_present() determines presence of the device
> and !vga_switcheroo_handler_flags() determine non-presence of its driver.)
> 
> This will also work if the subsystem depended on is compiled in rather
> than in a module.

Ah, interesting. Thanks Lukas. Sounds like we're going to be fine as is with
this particular case.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web