lkml.org 
[lkml]   [2016]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Allowing external modules to run across more configs and distros
From
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@gmail.com> 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?

\
 
 \ /
  Last update: 2016-02-13 09:41    [W:0.032 / U:2.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site