in linux kernel source codes, net/core/dev.c, the function netif_rx() calls trace_netif_rx_entry():
int netif_rx(struct sk_buff *skb)
{
trace_netif_rx_entry(skb);
return netif_rx_internal(skb);
}
However, I searched via grep and could not find the definition of trace_netif_rx_entry in the source codes. Then I googled still no answer. Could anyone help ?
I know the reason: a trick named Linux trace point
Related
Can anybody tell me the location where kernel hashtable struct hlist_head and struct hlist_node is defined in the linux kernel? I searched in free-electrons.com but couldn't get hold of the defination.
You can find it in types.h
http://lxr.free-electrons.com/source/include/linux/types.h#L189
It's also in a few other places. Check Linux Cross Reference.
http://lxr.free-electrons.com/ident?i=hlist_head
I wrote a module which uses EXPORT_SYMBOL(func) to export the function func.
When modifying the kernel code,
I declared extern void func(); at the top, and called func().
But when compiling kernel, I get undefined reference to 'func' error.
I guess the compiler can't find where func() is, but I don't know how to fix it.
Can someone help me out? Thanks a lot!
How can I force the linker to put some of my variables to specific place in memory. For example I want to allocate integer name in 0x8100000. If I didn't miss understand I can use:
int name __attribute__ ((section ("name_of_section")));
and then in linker scripts:
SECTIONS
{
...
. = 0x8100000;
.data : { name_of_section }
...
}
I want to use something similar for map a uC port.
But something doesn't match and I don't know where I made mistake. (I have never use linker script, so sorry if I wrote something very stupid).
Usually this is done without a linker script.
int volatile * const portA = 0x8100000; //portA is a constant pointer to a volatile int
...
*portA = 53; //write value 53 to output port
If you must use a linker script, it is going to be compiler and/or chip specific. Can you tell us what chip and toolchain you are using?
Thanks for all your advice! Now it's working.
.ld file:
SECTIONS
{
...
.data: {
...
}
...
var_name = 0x40010CA0;
}
.c file:
extern volatile int var_name;
After study docs which I linked above (Input Section Example), I tried also something like that:
.ld file:
.hrd_map 0x40010CA0 :
{
main.o(.b_section)
}
Where .b_section was a global variable with attribute:
int b __attribute__((section(".b_section")));
But it doesn't work, I got this kind of error: multiple definition of `main'.
I think that's because earlier in .ld file I have other asignment like: .data: {...} .bss .text.
Maybe someone know how to fix this, or how to get to some variables without using section attribute. I tried to look for symbols to variables in main.o file but I didn't see anything looking like symbol name for variable, except .b_section that I have created using section attribute and other (created by default? ) .data .bss .text etc.
#Dan You are right I am doing this for learning, and I agree with you. But on the other hand I think that this code will be quite portable beacuse every chip require .ld and Startup file and the definition of ports are also included in libraries.
I recommend NOT using the linker for access to hardware registers. Your code will be much easier to understand and maintain if you explicitly code the addresses. It is a good idea to gather all device-specific register information in an include file. For complex peripherals it is usually a good idea to typedef a structure for the register block associated with a peripheral, especially when the device supports several instances of a particular peripheral. Then use the technique from Luke's answer to get at the register or register block in your code. And the volatile keyword should always be used when accessing hardware registers.
I'm currently writing a Linux Kernel module which depends on the Linux Security Modules (LSM) at the moment it is nothing really, I just wanted to print out a simple message whenever a file is opened. The problem is: To register to the hook I need the function register_security, which - I found out after googleing - isn't exported anymore and thus can't be used by loadable kernel modules - only by modules which are compiled directly into the kernel.
Of course this makes sense for a security module, but it suckes for me developing.
So now the question to you: Is there a way of patching my module into the kernel? I mean, I don't want to recompile my kernel after every bugfix or for every minor change. I could live with rebooting my pc for every new try, but recompiling would take a little bit to long I guess..
Edit: Hm, noone yet :( I just had an idea, maybe someone can tell me if it's good or not: Can't I just add the EXPORT_SYMBOL in the kernel source for the functions I need, then recompile it and then add my code as a module? Of course this would be just for testing and debugging
Can't you just use fsnotify in kernel, or fanotify from user space?
It's not generally a good idea to export functions that the author didn't think it would be a good idea to export. If you call a function that isn't part of the public interface and that function has a side effect, you will probably break things. Besides, your module won't work on other machines, but maybe you don't care about this.
No, there is not. When a symbol is not exported, the in-kernel linker will not be able to find it. But adding the export to the kernel you use for testing should be OK. You can add your module to the export list by adding it to ./include/linux/Kbuild.
Also if testing in (user-mode-linux)[http://user-mode-linux.sourceforge.net/] or in virtual box, recompiling whole kernel might not be that big problem.
This may be a bit late as I see your question a while back. What I found to be a good solution is to write a module that you compile into the kernel and just exports the couple of functions you what to play with.
For example
//REGISTER FILE_PERMISSION
static void k_register_file_permission(int (*my_file_permission) (struct file *file, int mask)) {
my_file_permission_func = my_file_permission;
}
EXPORT_SYMBOL(k_register_file_permission);
Then you can just call k_register_file_permission from your kernel module, handy durring the development process.
You would also need a function like
int k_file_permission (struct file *file, int mask) {
if(my_file_permission_func == NULL)
{
//do nothing
}
else
{
return my_file_permission_func(file, mask);
}
return 0;
}
That you would register with the LSM at boot time.
I'm trying to build a shared library (DLL) on Windows, using MSVC 6 (retro!) and I have a peculiar link issue I need to resolve. My shared library must access some global state, controlled by the loading application.
Broadly, what I have is this:
application.c:
static int g_private_value;
int use_private_value() {
/* do something with g_private_value */
}
int main (...) {
return shared_library_method ();
}
shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method() {
use_private_value();
}
(Updated - I forgot the __declspec(dllexport) int __stdcall portion, but it's there in the real code)
How do I set up shared_library.dll so that it exports shared_library_method and imports use_private_value?
Please remember that A) I'm a unix programmer, generally, and B) that I'm doing this without Visual Studio; our automated build infrastructure drives MSVC with makefiles. If I'm omitting something that will make it easier to answer the question, please comment and I'll update it ASAP.
This is actually going to be pretty difficult to get working. On Unix/Linux you can have shared objects and applications import symbols from each other, but on Windows you can't have a DLL import symbols from the application that loads it: the Windows PE executable format just doesn't support that idiom.
I know that the Cygwin project have some sort of work-around to address this problem, but I don't believe that it's trivial. Unless you want to do lots of PE-related hacking you probably don't want to go there.
An easier solution might be to just have some sort of initializer method exported from the DLL:
typedef int (*func_ptr)();
void init_library(func_ptr func);
The application must call this at start-up, passing in the address of the function you want to share. Not exactly elegant, but it should work okay.
I'll start with half of the answer.
In shared_library.c:
__declspec(dllexport) int __stdcall shared_library_method(void)
{
}
The MSDN article about exporting function from DLL:s.
For the second half you need to export the functions from your application.c.
You can do this in the linker with:
/export:use_private_value#0
This should get you a lib-file that you build with your DLL.
The option to link the lib-file is to use GetProcAddress().
As DavidK noted if you only have a few functions it is probably easier to pass the function pointers in an init function. It is however possible to do what you are asking for.