Kernel Programming Questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Vadim Klishko wrote:
> On Friday, May 23, 2008 5:01 PM, "Greg KH" wrote:
> 
>> On Fri, May 23, 2008 at 04:42:41PM -0600, Vadim Klishko wrote:
>>> On Friday, May 23, 2008 4:00 PM, "Greg KH" wrote:
>>>
>>>> On Fri, May 23, 2008 at 02:32:46PM -0600, Vadim Klishko wrote:
>>>>> Hello Everybody,
>>>>>
>>>>> Could anyone please tell me what functions I could call from a Linux kernel module to:
>>>>>
>>>>> 1) dynamically load a library,
>>>> None.
>>>>
>>>>> 2) get the address of an exported function,
>>>> None.
>>>>
>>>>> 3) unload the library?
>>>> None.
>>>>
>>>> None of these things are things that you should do from within a kernel
>>>> module.
>>>>
> 
> First of all, I want to thank all those who answered for their suggestions.
> 
> Second of all, I suspect my question about loading a library within a kernel module may have been misunderstood. I am not talking about loading a user-space library. I am talking about loading my own library written specifically to be used in kernel space.
> 
> The idea is that the library is optional. If it is found on the system, then it is used. If it is not present, the module uses its internal, simpler algorithm. Any suggestions?

Create an out-of-tree kernel module to contain your "library". Access 
all of its public data and functions via pointers so that no in-tree 
kernel module depends on your optional one. Then in your driver, try to 
load the optional module using try_module_get(). There are plenty of 
examples of its use in the kernel sources. The optional kernel module 
would be installed under /lib/modules in the same place as all other 
modules.

Is the optional "library" proprietary (binary only)? If so, think 
carefully about GPL implications. Adding a simple GPL driver to expose 
proprietary hooks isn't good...

>>>>> Also, what are the functions that would allow me to read from and
>>>>> write to a binary or text file from within a kernel module?
>>>> None, this is not what a kernel module should ever be doing.
>>>>
>>>> Let's turn it around the other way, what are you trying to achieve that
>>>> makes you think the above things are necessary to do?
>>>>
>>> By reading a file, I am trying to load a system-wide device
>>> configuration. Of course, it could be hard-coded into the module, but
>>> why not try having it adjustable?
>> It's fine to be configurable, that's wonderful and something we do all
>> the time.
>>
>> But it is userspace sending the data into the kernel driver, not the
>> other way around.  With the plethera of different filesystems, mount
>> points, boot sequences, namespaces and the like, the kernel can not
>> specific a single location of a config file and have it work with all
>> systems.
>>
>> So have a startup script that parses the config file in userspace and
>> then writes the needed info into the driver using sysfs, or better yet,
>> configfs (which is sounds like what you need to use here.)
> 
> That would work. How do I read and write settings using configfs?
> 
>>>> The kernelnewbies mailing list and wiki covers the above topic in great
>>>> detail if you wish to understand why you should not be doing any of the
>>>> above from within the kernel.
>>>>
>>> Thank you for pointing me to kernelnewbies. I realize it's premature
>>> to argue before I have read their arguments against doing these things
>>> in the kernel, but the first objection that crosses my mind is this: I
>>> can do it in Windows. Why not in Linux?
>> Just because some other inflexible operating system allows you to do
>> this, don't assume that Linux with all of it's varied uses will follow
>> the same type of rules :)
>>
> Got your point! :-)
> 
>> Hope this helps,
>>
>> greg k-h

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux