On line 63 of this example header file there is a typedef:
typedef struct _snd_ctl_elem_info snd_ctl_elem_info_t;
There are multiple examples of typedefs like that through the code.
My goal is to get to the actual definition of the structure _snd_ctl_elem_info but I have grepped the source and googled but found no traces of the actual definition. Because of this search failure, I've started to think I might be missing some concepts and it might be something to do with kernel and backwards compatibility?
My motivation for this is to be able to gdb step through alsa and have an overview of the structures.
Is this some form of a low level structure definition pattern?
This structure is also used by alsa-lib to communicate with the kernel, so it just reuses the kernel's definition.
The kernel header would be installed as /usr/include/sound/asound.h, but to avoid a dependence on the kernel headers being installed correctly, alsa-lib has its own copy of this file in alsa-lib/include/sound/asound.h.
Applications are not supposed to access the members of this structure directly, so alsa-lib does not include asound.h from its official headers (and does not even install it; it's used only when compiling alsa-lib).
To get the actual definition, you would need #include <sound/asound.h>.
It sounds like it gets renamed from a typedef:
#define _snd_ctl_elem_info sndrv_ctl_elem_info
So you're looking for sndrv_ctl_elem_info, which is way easier to find.
It is defined in asound.h at line 809.
It's pretty massive so I won't paste it here.
It is defined in API header snd/asound.h. This is what client code is supposed to #include.
Related
I am a beginner in the field of Linux kernel programming. I was studying Linux Security Modules (LSM). The references which I have seen (recent ones) especially this video here, bakes the module written into the kernel itself, and then the entire compiled kernel is installed on say an Ubuntu machine.
I was thinking of writing a program, such that instead of making it into the kernel itself, I could load and unload it as per my need. (Especially to test the correctness of its functionality, easily).
The video which I have mentioned above makes use of security_add_hooks to bind our function to the security subsystem. But, using the mention of security_add_hooks and LSM_HOOK_INIT which in turn uses security_hook_heads struct, causes an issue when I try to make a .ko file for this module.
ERROR: modpost: "security_add_hooks" [security/my_test.ko] undefined!
ERROR: modpost: "security_hook_heads" [security/my_test.ko] undefined!
I can understand that security_add_hooks is a function and has not been exported for use by the modules. So, I tried to EXPORT_SYMBOL(security_add_hooks) so that my .ko file can use it.
But another issue arises. Regarding two struct definitions, security_hook_heads and security_hook_list. I simply don't know how to export them. I tried to write a statement EXPORT_SYMBOL(security_hook_heads); just after the corresponding struct definition as follows, in lsm_hooks.h:
struct security_hook_heads {
#define LSM_HOOK(RET, DEFAULT, NAME, ...) struct hlist_head NAME;
#include "lsm_hook_defs.h"
#undef LSM_HOOK
} __randomize_layout;
EXPORT_SYMBOL(security_hook_heads);
Corresponding to this I get the following error:
./include/linux/lsm_hooks.h:1601:15: error: ‘security_hook_heads’ undeclared here (not in a function)
1601 | EXPORT_SYMBOL(security_hook_heads);
I don't fully understand the meaning of the error, but I feel it is trying to point out that exporting a symbol from a header file is not possible.
So, I could not figure out how to work out this approach. Is there any other easy method available?
I was going through a few old YouTube videos and a few articles, where they make use of functions like register_security and unregister_security, but I guess these functions are no longer there in the latest Linux kernel (6.0.0). [As was mentioned in the thread of the following few questions: (1), see the comment to the answer for the previous question, (2)]
You can't do this in a module.
security_add_hooks is marked with __init.
It is linked into a special linker section (e.g. .init.text).
At a certain point in the kernel startup (see: kernel_init) it calls free_initmem.
After that, the memory occupied by these functions is reclaimed and can be used as ordinary memory.
So, by the time your module is loaded, security_add_hooks et. al. are long gone.
If you have to modify security/security.c to add EXPORT_SYMBOL(security_add_hooks), then you are building a custom kernel. So, you might as well just bake your code into the kernel.
I'm not new to C programming but I havn't got the chance to touch it for a lot of time.
I'd like your advice on a way to define data structures (struct) which are defined in a configuration file. At the moment, I haven't defined the structure for the configuration file but I'm guessing it will be something like ini file.
Basically I'm working on Windows and Linux so I'd love an answer for both OS.
I'd like your advice on a way to define data structures (struct) which are defined in a configuration file
The simplest method, by far, would be to use header (.h) files as your configuration files. You could include them into your project like so:
#include CONFIG_FILE
... and introduce them during compilation like so:
cc -D'CONFIG_FILE="path/to/config.h"' path/to/source/files.c
If you wrap all of your config values into function-like-macros from the very start, this should be nice and flexible; you shouldn't have a problem generating clean structs from your INI files.
I'm guessing it will be something like ini file
I should point out that in the world of C, define has a very strict meaning, and to define data structures (struct) can only be done in C source files (or header files, which are later included into source files).
Suit yourself! My recommendation would give you an interface that allows you to put the lexing/parsing on hold until a (much) later point in time (i.e. when you have the time to write a full-fledged INI-to-C-header compiler, because that's what you're asking about), and give you an interface with which to fill in the blanks, so to say.
Specifically, my issue is that I have CUDA code that needs <curand_kernel.h> to run. This isn't included by default in NVRTC. Presumably then when creating the program context (i.e. the call to nvrtcCreateProgram), I have to send in the name of the file (curand_kernel.h) and also the source code of curand_kernel.h? I feel like I shouldn't have to do that.
It's hard to tell; I haven't managed to find an example from NVIDIA of someone needing standard CUDA files like this as a source, so I really don't understand what the syntax is. Some issues: curand_kernel.h also has includes... Do I have to do the same for each of these? I am not even sure the NVRTC compiler will even run correctly on curand_kernel.h, because there are some language features it doesn't support, aren't there?
Next: if you've sent in the source code of a header file to nvrtcCreateProgram, do I still have to #include it in the code to be executed / will it cause an error if I do so?
A link to example code that does this or something like it would be appreciated much more than a straightforward answer; I really haven't managed to find any.
You have to send the "filename" and the source of each header separately.
When the preprocessor does its thing, it'll use any #include filenames as a key to find the source for the header, based on the collection that you provide.
I suspect that, in this case, the compiler (driver) doesn't have file system access, so you have to give it the source in much the same way that you would for shader includes in OpenGL.
So:
Include your header's name when calling nvrtcCreateProgram. The compiler will, internally, generate the equivalent of a std::map<string,string> containing the source of each header indexed by the given name.
In your kernel source, use #include "foo.cuh" as usual.
The compiler will use foo.cuh as an index or key into its internal map (created when you called nvrtcCreateProgram), and will retrieve the header source from that collection
Compilation proceeds as normal.
One of the reasons that nvrtc provides only a "subset" of features is that the compiler plays in a somewhat sandboxed environment, without necessarily having all of the supporting tools and utilities lying around that you have with offline compilation. So, you have to manually handle a lot of the stuff that the normal nvcc + (gcc | MSVC| clang) combination provides.
A possible, but non-ideal, solution would be to preprocess the file that you need in your IDE, save the result and then #include that. However, I bet there is a better way to do that. if you just want curand, consider diving into the library and extracting the part you need (blech) or using another GPU-friendly rand implementation. On older CUDA versions, I just generated a big array of random floats on the host, uploaded it to the GPU, and sampled it in the kernels.
This related link may be helpful.
You do not need to load curand_kernel.h yourself and add it to the include "aliases" mechanism.
Instead, you can simply add the CUDA include directory to your (set of) include paths, e.g. by adding --include-path=/usr/local/cuda/include to your NVRTC compiler options.
(I do this in my GPU-kernel-runner test harness, by default, to be on the safe side.)
As an example: on my system (Ubuntu 10.04), the sockaddr structure is defined in /bits/sockaddr.h as
struct sockaddr{
_SOCKADDR_COMMON (sa_); /*...*/
char sa_data[14]; /*...*/
};
and similarly for sockaddr_in, with first field name sin_.
However, all the examples I see access the field sin_
structure_name.sin_family
I meant to track down the typedef (?) for completeness, followed included headers and such, but failed (I got to sa_family_t and similar).
As a more general question: is there, say, a searchable online source where you can simply search for where a macro or typedef is in the header files - either for a particular Ubuntu distribution, or more generically for 'typical' Linux installations? Or, obviously, a clever way from within Ubuntu's shell; or some description of how to be more efficient doing this any other idea.
This is the link:
LXR / The Linux Cross Reference
done...i'll get you the reference for the Linux Kernel API Browser later (used to be able to find it online somewhere). There's the Linux Kernel Archives for the actual source code, which you probably could generate documentation from anyways.
Sorry, but I've not come across something as beautiful as say, the
jQuery API Browser. Hopefully the 'Ubuntu Manpage' #
manpages.ubuntu.com/manpages/lucid/man7/netdevice.7.html, for example,
might suffice. Also for stuff like the struct sockaddr{, you might
like to check out the Linux Kernel API Browser (or something similar)
as that belongs to standard Linux networking protocol headers.
You could try: http://www.google.com/codesearch perhaps?
What do you do when you have a set of .h files that has fallen victim to the classic 'gordian knot' situation, where to #include one .h means you end up including almost the entire lot? Prevention is clearly the best medicine, but what do you do when this has happened before the vendor (!) has shipped the library?
Here's an extension to the question, and this is probably the more pertinent question -- should you even attempt to disentangle the dependencies in the first place?;
I've done this on a C++ code base that was already split into many libraries (which was a good start).
I had to workout (or guess) which library was the most depended upon, which depended upon nothing else in the code base. I then processed each library in turn.
I looked at each module (*.cpp files) in turn and made sure that its own header was #included first and commented out the rest, then I commented out all the #includes in that header file and then re-compiled just that module to let the compiler tell me what was needed. I would un-comment the first header that seemed to be needed, and reviewed that one, recursing as necessary. It was interesting to see how many headers ended up not being needed.
Where only the name is needed (because you have a pointer or reference) use class name; or struct name;, which is called forward declaration and avoid #including the header file.
The compiler is very helpful in telling you what the dependencies are when you comment out #includes (you need to recompile with ALL the compilers you have to maintain portability).
Sometimes I had to move modules between libraries so that no pairs or groups of libraries were mutually dependant.
As you have the opportunity, you should refactor the code to reduce includes that are too large, however that assumes you can achieve some sort of package cohesion. If you disentangle things just to discover that every user of the code has to include all the elements anyway, the end result is the same.
Another option is to use #defines to configure sections on and off. Regardless, for an existing code base the solution is to move toward package cohesion.
Read: http://ivanov.files.wordpress.com/2007/02/sedpackages.pdf and research issues related to package cohesion.
I've untangled that knot a few times, and it generally helps a lot when maintaining a system to reduce the .h dependencies as much as possible. There are decent tools for generating dependency trees ( I was using Klocwork at the time ).
The downside I found was with conditional compilation. Someone might remove a header file because they think we don't need it, but it turns out that we only don't need it because VxWorks has some screwed up headers... on Solaris (or any reasonable Posix system) you do need it.
There is a balance to be struck between an enormous number of finely organized headers and a single header that includes everything. Consider the Standard C library; there are some biggish headers like <stdio.h>, which declares a lot of functions, but they are all related to I/O. There are other headers that are more of a miscellany - notably <stdlib.h>.
The Goddard Space Flight Center guidelines for C are worth hunting down.
The basic rule is that each header should declare the facilities provided by a suitable (usually small) set of source files. The facilities and header should be self-contained. That is, if someone needs the code in header "something.h", then that should be the only header that must be added to the compilation. If there are facilities needed by "something.h" that are not declared in the header, then it must include the relevant headers. That can mean that headers end up including <stddef.h> because one of the functions uses size_t, for example.
As #quamrana points out, you can use forward declarations for structures (not classes, since the question is tagged C and not C++) when appropriate - which primarily means when the interface takes pointers and does not need to know the size of the structures or any of the members.