lkml.org 
[lkml]   [2013]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/2] ion: Don't allow building ION as a module.
From
On Sat, Dec 14, 2013 at 2:19 PM, John Stultz <john.stultz@linaro.org> wrote:
> On 12/14/2013 01:48 PM, Greg KH wrote:
>> On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote:
>>> ION doesn't export the proper symbols for it to be a module. This
>>> causes build issues when ION is configured as a module.
>>>
>>> Since Andorid kernels rarely use modules (I think recent policy
>>> requires no modules?), go ahead and set the ION config to a bool
>>> from the tristate option.
>>>
>>> If folks decide ION as a module is important, we will have to go
>>> through and export the various needed symbols.
>>>
>>> Signed-off-by: John Stultz <john.stultz@linaro.org>
>>> ---
>>> drivers/staging/android/ion/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
>>> index a342d96..b95281e 100644
>>> --- a/drivers/staging/android/ion/Kconfig
>>> +++ b/drivers/staging/android/ion/Kconfig
>>> @@ -1,5 +1,5 @@
>>> menuconfig ION
>>> - tristate "Ion Memory Manager"
>>> + bool "Ion Memory Manager"
>> Or you can do:
>> depends on m
>> and leave it as a "tristate", then when switching it off, I think you
>> can then be prompted as 'm' again, but I could be wrong about that.
>>
>> So should ION ever be able to be built as a module in the future?
> My understanding is that Android is moving away from using modules, but
> others could comment more authoritatively. So I don't think this is an
> issue. But as I said in the patch, if folks do want to have ION as a
> module, we'll have to export all the various symbols that ION users need.

There's no reason ION couldn't be built as a module, it just doesn't
make much sense given how central it is to the Android devices it is
used on. It will need some TODOs fixed in the removal paths, and
probably some refcounting to prevent removing the module while buffers
are allocated.

As for modules in general on Android, they are rarely used on ARM
Android devices and were considered a security risk. I don't think
anybody would have a problem re-enabling them if
CONFIG_MODULE_SIG_FORCE was also enabled.


\
 
 \ /
  Last update: 2013-12-15 00:21    [W:0.173 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site