I am working on a project that is migrating from linux kernel 2.6 to 3.10.
The 2.6 version contained calls to api daemonize() which is not longer available in newer kernel.
So far i have seen kthread_run() as a replacement. However, when i put in kernel_thread() with function to start, null and string name as arguments, i got lots of : "can't fork" errors.
Can any one advice upon the correct replacement?
To manage a kernel thread, you should use the helper functions in <linux/kthread.h> such as kthread_run().
Related
Is it possible to compile mod_go.c successfully and produce the Apache module (mod_go.so) for GOLANG in Windows environment?
Unfortunately i can not find any detailed instructions such as type of C++ compiler, apache version etc as well as what steps i have to follow?
Regards
Probably that is not possible, but I leave you to check.
Go plugins are only supported on Linux. So if you absolutely need to code Apache modules in Go (which requires dynamic loading of shared object produced by the Go compiler, that is a plugin coded in Go), you'll better switch to Linux. BTW the linker model of Windows is very different from Linux, so it won't change easily and I won't be surprised that Go won't have plugin on Windows for a few years.
Linux dlopen(3) (actually a POSIX feature) and its shared libraries (ELF shared objects, containing position-independent code) are very different from Windows LoadLibrary and DLLs.
Read Levine's Linkers and Loaders book and (for Linux) Drepper's paper How To Write Shared Libraries
So if you badly need to write this year (e.g. before the end of 2018) a plugin in Go to be used by Apache, I strongly recommend switching your Apache server machine to Linux.
BTW, it looks like your mod_go don't use Go plugins (but communicate with some external process, I leave you to study its source code, I only glanced into it) Perhaps using FastCGI could be simpler, since Go has FastCGI support. Probably Windows' Apache could be configured to talk to some FastCGI application (notice that FastCGI is not CGI).
(I don't know Windows, never used it, but read a few things about its weird -and IMHO inferior to Unix- linking model)
I'm building an application with OpenGL ES 2.0 and SDL2 for Android. Is SDL_GL_GetProcAddress working with OpenGL ES 2.0 on Android? Also i know OpenGL ES 2.0 is a subset of OpenGL, so with this method can it run on desktop systems too?
From a quick browse of the SDL repository it should be.
SDL_video.c defines the implementation of SDL_GL_GetProcAddress simply to check that you've started OpenGL and then to call _this->GL_GetProcAddress, where _this is a global instance of the video driver.
SDL_androidvideo.c sets its GL_GetProcAddress to be Android_GLES_GetProcAddress, which is a preprocessor substitution for SDL_EGL_GetProcAddress.
So, so far: if you call SDL_GL_GetProcAddress, you'll get through to SDL_EGL_GetProcAddress.
SDL_egl.c implements SDL_EGL_GetProcAddress but declines to call eglGetProcAddress on Android. This looks like it's probably an error — the reason given is this bug but the status for that bug switched to 'Released' in June 2013, which I believe means that this has been fixed in Android for more than three years.
That aside, the fallback is to use SDL_LoadFunction, first with the direct function name, then with it proceeded by an underscore provided it's short enough to fit into the statically-declared buffer. Which this one is.
(so, caveat: SDL_GL_GetProcAddress is definitely not thread-safe, even if you've taken appropriate share group steps to use multiple GL contexts, but if you're writing an SDL program you probably don't care)
Android should be using the dlopen version of SDL_sysloadso so it looks like SDL_LoadFunction is implemented directly as a call to dlsym. Which has no issues that I'm aware of under Android.
So, in summary: yes, that call should work. It'll use the platform-specific dynamic library loader rather than the EGL call though it probably doesn't need to, but that's just an implementation detail.
The CUDA FAQ says:
CUDA defines vector types such as float4, but doesn't include any
operators on them by default. However, you can define your own
operators using standard C++. The CUDA SDK includes a header
"cutil_math.h" that defines some common operations on the vector
types.
However I can not find this using CUDA SDK 5.0. Has it been removed/renamed?
I've found a version of the header here. How is it related to the one that's supposed to come with SDK?
The cutil functionality was deleted from the CUDA 5.0 Samples (i.e. the "SDK"). You can still download a previous SDK and compile it under CUDA 5, you should then have everything that came with previous SDK's.
The official notice was given by nvidia in the CUDA 5.0 release notes (CUDA_Samples_Release_Notes.pdf, installed with the samples). As to why, I imagine that the nvidia sentiment regarding cutil probably was something like what is expressed here "not suitable for use in a real application. It is completely unsupported" but people were using it in real applications. So one way to try put a stop to that is to delete it, I suppose. That's just speculation.
Note some additional useful info provided in the release notes:
CUTIL has been removed with the CUDA Samples in CUDA 5.0, and replaced
with helper functions found in NVIDIA_CUDA-5.0/common/inc:
helper_cuda.h, helper_cuda_gl.h, helper_cuda_drvapi.h,
helper_functions.h, helper_image.h, helper_math.h, helper_string.h,
helper_timer.h
These helper functions handle CUDA device
initialization, CUDA error checking, string parsing, image file
loading and saving, and timing functions. The CUDA Samples projects no
longer have references and dependencies to CUTIL, and now use these
helper functions going forward.
So you may find useful functions in some of those header files.
in latest SDK helper_math.h implement most of required operator, however its still missing logical operators like OR or AND
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
Is there any way to print the runtime stack trace of a Ruby 1.9.x process? I know that there was a utility called pstack for Ruby 1.8, but the project appears to have been abandoned a couple years ago: https://github.com/ice799/pstack. Does anything like this exist for Ruby 1.9? Thanks a lot!
EDIT: I'm interested in using an external tool to generate the stack trace (not running in the same memory space as the Ruby process).
As #mosch pointed out, the Kernal#caller method works from within the running Ruby process.
You could even build in support to your Ruby code that traps process signals and prints a stack trace:
Signal.trap("SIGTERM") { p caller }
Reference: http://www.ruby-doc.org/core-1.9.3/Signal.html
I could build this functionality into my code, but I'd prefer to use a more generalized, external solution. Thanks.
Whenever you call the Kernel method caller, you will get the current call stack as an Array.
I came up with an idea on this today. The pstack from ice799 took advantage of gdb to call a ruby internal function to dump the backtrace. However, it didn't work for 1.9 and required a patch. It's not such convenient.
With luck, we have hotpatch this powerful tool. It can inject a .so to a running process, we can add the required function via .so injection, pstack will do all the rest. Of course the injected .so need be binary compatible with the running ruby core, but we can assume this part is very stable now.