I would like to be able to write eBPF programs for my customer kernel.
The problem is when I modify the kernel and add trace points for example, I won't be able to install bpfcc-tools package because they do not have that package built for my custom kernel.
So, I would like to find a way to write these programs without depending on pre-built packages.
Related
I would like to distribute a Windows/Linux application that uses openCL, but I can't find the best way to do it.
For the moment my problem are only on Windows:
1- I'm using Intel CPU, how can I manage Intel AND AMD (CPU of final users) ?
2- For distribution of application that uses Visual Studio DLL, we have Visual Studio Redistributable to manage this easily and to avoid a big installation of Visual Studio. Is there a package like this for openCL ?
3- Finally, I don't know if I must provide OpenCL.dll or not (example of different point of view here)
I read several topics on the web about this problem without clear solution.
Thank you for your help.
1) You write to the OpenCL API and it works with whatever hardware your user has. User the header for the lower version you want to support (e.g., use cl.h from 1.1 if you want to target 1.1 and higher).
2) The OpenCL runtime is installed on the user's machine when they install a graphics driver. You don't need to (and should not) redistribute anything.
3) Please don't redistribute OpenCL.dll
The one problem you may need to deal with is if your user does not have any OpenCL installed on their machine. In this case, the call to clGetPlatformIDs will fail. There are various ways to deal with this, all platform specific. Dynamically linking to OpenCL.dll is one way, or running a helper process to test for OpenCL is another. An elegant solution on Windows is to delay load OpenCL.dll and hook that API to return 0 if the late binding fails.
1- I'm using Intel CPU, how can I manage Intel AND AMD (CPU of final users)
Are you talking about running OpenCL kernels on CPU, or just host-side code while kernels run on GPU ? because if the former (on CPU), your users will need to install their respective OpenCL CPU implementation, IIRC the Intel CPU implementation does not run on AMDs (or at least that used to be the case, perhaps it's now different..)
3- Finally, I don't know if I must provide OpenCL.dll
You don't have to, but you should, IMO. The way OpenCL works (usually), OpenCL.dll is just an ICD loader - a small library (a few dozen KB) that loads the actual OpenCL implementation(s) by looking into a few predefined places. It should be safe to include on Windows, and it simplifies your program logic - you can always build with OpenCL enabled, and if there's no OpenCL implementation installed, the loader will return CL_PLATFORM_NOT_FOUND_KHR - you just handle that error by asking user to install an OpenCL implementation, or fallback to non-OpenCL code path if you have it, whatever suits you more.
There's no need to complicate your life with delayed DLL loads or helper processes. In fact that's the entire point of the ICD concept - you don't need to look for the platforms and DLLs yourself, you let the ICD loader do it. It's pretty absurd to write helper code to load a helper library (ICD) which then loads the actual implementation DLLs...
I would like to modify the linux kernel.
I would like to use functions from a shared library (an .so file) in file kernel/panic.c.
Unfortunately I don't know how to compile it.
When I put it in to the Makefile I receive the following error:
ld: attempted static link of dynamic object.
Is there a way to put the shared library file to the Linux kernel or do I need to recompile my library to gain an object file.
It is not possible to link shared library into kernel code (ELF shared objects are a user-space thing, using ld-linux(8)...) You should consider making a kernel module (and use modprobe(8) to load it). Read Loadable Kernel Module HowTo.
kernel modules *.ko are conceptually similar to shared objects *.so but the linking mechanism is different.
BTW, you generally should avoid writing kernel code and should prefer coding application code. In other words, modifying the kernel is generally a bad idea and is frowned upon.
Also, the API available in kernel space is not the same as user space API (which extends the C standard library and POSIX functions). For example, kernel modules (and kernel code) don't have (so cannot call) fopen or fprintf or fork; the kernel is a freestanding C application. Also, kernel code cannot use any floating point operation!
Userland applications are interacting with the kernel using system calls listed in syscalls(2) (and the libc is using them, e.g. for printf or system(3)). Kernel code (including kernel modules) cannot use directly syscalls (since they are provided by the kernel, see syscalls(2)).
Read also Advanced Linux Programming (mostly about application programming) and Operating Systems: Three Easy Pieces (to get a broader view about OSes).
Basically I want implement my own semaphore inside the linux kernel and be able to use it in user programs.
I've made some progress implementing the kernel code however I do not know how to make semaphore type and the functions I've written available to user programs.
User programs would need to have access to my semaphore type and its functions (wait, signal, ...)
Is there any way to this so that a linux using a kernel compiled with my code would be able to use my semaphore simply by including a header file?
I'm no pro when it comes to the linux kernel, so if I'm making any obvious mistakes feel free to point them out.Thanks.
The kernel version I'm using is 2.6.32.
I would recommend looking into the user space libraries for how a semaphore implemented for user space programs.
Semaphores are only available in kernels older 2.6.16 kernels, as mutex's appeared after that version of the kernel. Only the previous implementation used semaphores. The newer code should use mutexes instead which are used only in process context. You may want to look the following headers, struct's and api's.
#include <linux/mutex.h>
struct mutex
mutex_{lock,trylock,unlock,lock_interruptable}()
Also you may want to look semaphore.c for the implementation.
I am asking here because I have no idea where to find any information about this problem. If you could recommend me a book or an article about it, I would be pleased.
Where can I find any information about correlation between Linux kernel and GLIBC's version? I know that, the kernel itself contains implementation of libc's functions, but I do not know, how they are delivered to it.
For example:
Recently I had to build the kernel for an old PowerPC processor. It came with libc's dynamic library files in version 2.3.6 out-of-the-box. In /lib/ path there are files with names like librt.so-2.3.6.
What is the simplest way to update this lib to a newer version?
Is it possible to configure kernel's build system to make it generating uImage file with a newer GLIBC version or an alternative one (ex. EGLIBC)?
There is little correlation, the same kernel should work with a wide range of glibc versions, and viceversa. The library finds out what the kernel handles, and uses that. For the gory details of what has changed in glibc (this is what you interact with, including support for new kernel features), you should look at the upstream changelog. For new features in the Linux kernel, perhaps the best source are the periodical "What's new in..." articles the kernel section of LWN
Matlab has msgbox, listdlg, textscan, and many other functions that Octave apparently doesn't have. Is there any extra library with functions like this? Or perhaps different-named functions that will show a message dialog, let user select a data file to process, and read in formatted file?
Check out octave forge. It has msgbox, listdlg and other related methods. There are installation instructions on the home page.
If you are using a Debian-based distribution like Ubuntu or Linux Mint, then you can use the functions mentioned (msgbox, listdlg etc.) by installing the precompiled package octave-java.
In general, the Debian project (and, by side-effect, derived distributions) tries to package as many packages as reasonable from Octave-Forge to provide a Free alternative to proprietary packages like Matlab (sometimes, these packages can provide also implementation of functions of some of the parts of extra/paid Matlab toolboxes).
I am sure that other fine, reputable, high profile Linux distributions (like Fedora) also provide many packages from Octave-Forge, as they also have a policy for such packages.