Re: Allowing external modules to run across more configs and distros
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. 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. 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?
Re: Allowing external modules to run across more configs and distros
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. 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?
Re: Allowing external modules to run across more configs and distros
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.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. 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?
Re: Allowing external modules to run across more configs and distros
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.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?
Allowing external modules to run across more configs and distros
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?
Allowing external modules to run across more configs and distros
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?