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

[David F.]

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?