Re: Allowing external modules to run across more configs and distros

[David F.]

To follow up on this, to make the existing version check system
continue to work, it would only check those modules that reference the
"struct modconfigopts", either by way of a compiler option on the
macro, or just recommendation that coder create an external reference
to whatever is needed to make the modversions create a reference to
it.

On Sat, Feb 13, 2016 at 12:13 AM, David F. <df7729@xxxxxxxxx> wrote:
> After sending the below, I realized that if someone doesn't want to
> have to dereference a pointer it could still be done the same way and
> just omitting the member variable (options).  You would just always
> allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
> access the options, use a different macro: #define MOD_OPT(m) ((struct
> modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
> modconfigopts*)((int8_t*)(m)+sizeof(*m)))
> example of when an optional item is reference:
> MOD_OPT(THIS_MODULE)->param_lock
>
> now you don't have any dereferencing of the pointer.
>
>
> On Fri, Feb 12, 2016 at 11:45 PM, David F. <df7729@xxxxxxxxx> wrote:
>> While creating a linux module that should be usable across a wide
>> array of linux versions and builds, I've run into struct modules
>> (THIS_MODULE) being a problem.  It's the only internal struct accessed
>> as a requirement to struct block_device_operations .owner.   It's a
>> bit annoying for this module to be rejected for nothing it has any
>> interest in using.  So I was thinking of a quick solution but don't
>> want to waste my time if people will resist it (not sure when I'll
>> have time to do it, but should be able to do it quickly once i'd have
>> all the source local).  The idea is:
>>
>> Take all #if defines out of the struct module and place them in a
>> separate struct (struct modconfigopts).  Place a single member
>> variable at the end of struct modules as void * (void *options) to
>> access the options.  Have a single macro to access the options member
>> variable for the internal code that access it (#define MOD_OPT(v)
>> ((struct modconfigopts*)(v)).  So internal code would use
>> module->MOD_OPT(options)->param_lock for example.
>>
>> When the module structure is created, it would initialize the options
>> member variable (the memory allocated (sizeof(struct
>> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
>> one big structure, then cleanup would be the same).
>>
>> Doing this should then allow "external" modules that don't need access
>> to the "internal" config options to continue to load and work across a
>> much greater range of Linux distributions.
>>
>> What do you think?