I am trying to implement a spin lock using the test_and_set_bit function. I found a bitops.h file which consisted of this function. However, in my current kernel version which is 3.0, the function is not included in that header file i.e, bitops.h. Any anyone provide some references where I can find that?
Not sure if I totally understand your question, but including <linux/bitops.h> should bring in the definition of test_and_set_bit(). The actual definition of the function is not in include/linux/bitops.h but it is picked up via the include of <asm/bitops.h> that is in the linux/ version of the include.
So to see the actual definition of test_and_set_bit() you can look in arch/arm/include/asm/bitops.h or arch/x86/include/asm/bitops.h (or whatever other architecture you're interested in).
By the way, there's no reason to need to implement your own spinlock -- the kernel has (of course) the standard spinlock_t and also functions like bit_spin_lock() that use a single bit as a lock.
Related
I'm a little confused going about adding a new instruction to QEMU and want to confirm if my understanding is right. After going through the source code, I think adding an instruction to QEMU involves the following steps:
Define a helper function of the format CHERI_HELPER_IMPL(*instruction* in \target\target_arch\op_helper.c that emulates this instruction.
Define generate_*instruction* in \target\target_arch\translate.c that calls gen_helper_*instruction* which calls the helper function.
Am I missing any steps?
The fact that you mention a "CHERI_HELPER_IMPL" macro tells me that you're not working with upstream QEMU, but with the CHERI project's fork of it. So you should talk to them about anything special that might be needed there. As I understand it their local modifications may be quite significant.
For upstream QEMU, this depends on whether the target architecture is using decodetree or not.
For decodetree-based architectures:
add a suitable instruction pattern or patterns to the .decode file. This will result in the generation of code which calls a function whose name begins trans_ to handle instructions that match that pattern, passing it a pointer to a structure which contains the values of the various instruction fields defined by your pattern.
implement the trans_ functions appropriately. What you need to do depends on what the instruction behaviour is. For simple instructions, you can just emit TCG ops which do the actions the instruction must do. For more complicated work, you might want to emit TCG ops for "call a runtime helper function". The tcg/README file has some "recommended coding rules" at the bottom which include a rule of thumb for when to use a helper function.
if you decided to emit a helper call, you need to implement the helper function. The DEF_HELPER_* macros in helper.h both define the prototype for the C function you're going to write and also auto-generate a function gen_helper_whatever that your translate-time code can call to generate the TCG code to call it.
For non-decodetree-based architectures:
There will be hand-written code, usually starting in translate.c, which identifies instructions using switch statements and bit-masking code. You'll need to look at that code to find out where in that to add the code which identifies the instruction that you're adding. This is all completely target-specific; some targets use a somewhat table-driven setup or some preprocessor macros as part of this, some use completely hand-written code.
Once you've figured out where to add the "is this my instruction type?" check, the rest is similar to decodetree-based targets: you need to emit TCG ops to either do the work or to call a helper to do the work at runtime.
You'll find that there's a lot of specific detail that needs to be got right in each of these steps, but that's the basic outline.
I would like to provide individual names to the threads in my Rust program. These names should appear in top/htop so I can differentiate the thread's job. In Ruby I would modify the argv[0] entry, or maybe Process.setproctitle("foo"). My inspiration is from Ruby's Unicorn web server.
The env::args function returns an Args value. The Args value wraps the platform-specific std::sys::args::args() function which is not reexported for general use. ArgsOs doesn't have a usable mutator (so yes, the stdlib makes it clear it is immutable).
How do I mutate the arguments some other way? I am happy with a Linux-only solution since that is where the real work will happen. Solutions outside the stdlib are also fine.
What path should I take in order to modify the first argument in the environment of my process?
How can I replace an entry in std::env:args()
You cannot. Immutable means immutable.
I would like to change how my Rust program appears in top/htop
There is nothing like this in the standard library. As far as I know, there's no cross-platform solution, so it would be a hard fight to put in there.
Linux
Seems to have a simple enough solution: Change process name without changing argv[0] in Linux
If you only care about Linux, you can use the prctl crate:
prctl::set_name("new_process")
macOS
Has various concepts of "process name" and the solution is complex and uses undocumented / hidden APIs: Setting process name on Mac OS X at runtime
Everything in that answer could be written in Rust using the appropriate bindings to the macOS APIs.
Windows
Does not seem to have such a concept: Changing a process name in runtime
Cross-Platform
Someone could write a crate that abstracts across these different mechanisms, but I'm not aware of one.
so I can easily spot what all my threads are doing
As mentioned in the comments, when you create a thread, you can give it a name. Some work was recently put into renaming threads at run time, but that work stalled out.
I wrote the proctitle crate for setting process titles in a cross-platform manner. On Linux it does happen to name the current thread, but this is a quirk of the APIs it provides rather than a deliberate choice.
I have a driver that raises some warnings/errors during compilation, since the proc_fs api changed since its creation. The driver still uses create_proc_entry while the latest api version I am aware off, offers proc_create. Since I am new to driver programming under linux I tried to look at the source, however my ctags skills must be lacking since I only found proc_create in proc_fs.h. However, I would like to look at the implementation or some documentation, to know what error codes it returns so I know what I have to handle.
Can you point me to documentation for the proc api, or the source holding the definition of proc_create? A hint how it can be found would be appreciated as well.
create_proc is defined as an inline function, so it is fully implemented in the header proc_fs.h. It basically calls proc_create_data with a NULL for the data argument.
There seems very little documentation on these functions in the source so I'd recommend looking at other call sites within the kernel source, which you cam see listed in this LXR search.
BTW, creating new files in /proc seems frowned upon these days - it seems sysfs is where new interfaces should be created.
Best documentation for an API would be existing code itself. Check a few c files in fs/proc or grep for proc_create in the source code
I want to make a quick fix to one of the project's .so libraries. Is it safe to just recompile the .so and replace the original? Or I have to rebuild and reinstall the whole project? Or it depends?
It depends. Shared library needs to be binary-compatible with your executable.
For example,
if you changed the behaviour of one of library's internal functions, you probably don't need to recompile.
If you changed the size of a struct (e.g. by adding a member) that's known by the application, you will need to recompile, otherwise the library and the application will think the struct is smaller than it is, and will crash when the library tries to read an extra uninitialized member that the application didn't write to.
If you change the type or the position of arguments of any functions visible from the applications, you do need to recompile, because the library will try to read more arguments off the stack than the application has put on it (this is the case with C, in C++ argument types are the part of function signature, so the app will refuse run, rather than crashing).
The rule of thumb (for production releases) is that, if you are not consciously aware that you are maintaining binary compatibility, or not sure what binary compatibility is, you should recompile.
That's certainly the intent of using dynamic libraries: if something in the library needs updating, then you just update the library, and programs that use it don't need to be changed. If the signature of the function you're changing doesn't change, and it accomplishes the same thing, then this will in general be fine.
There are of course always edge cases where a program depends on some undocumented side-effect of a function, and then changing that function's implementation might change the side-effect and break the program; but c'est la vie.
If you have not changed the ABI of the shared library, you can just rebuild and replace the library.
It depends yes.
However, I assume you have the exact same source and compiler that built the other stuff and now if you only change in a .cpp file something, it is fine.
Other things e.g. changing an interface (between the shared lib and the rest of the system) in a header file is not fine.
If you don't change your library binary interface, it's ok to recompile and redeploy only the shared library.
Good references:
How To Write Shared Libraries
The Little Manual of API Design
I'd like to add a new system call via an LKM, but I'm not sure how to do this. That is, I know that if I want to add a completely new system call, I can look through the sys_call_table and find a sys_ni_syscall and just replace it, but I was curious if it was possible to actually add to the sys_call_table. I realize it's probably not possible, given that it's a fixed size array, but I was wondering if there were any other clever ways to add system calls without overriding an unused system call number.
Here's an example
linux system calls
edit:
The example above shows howto implement a system call, as far as implementing one from a loadable module; AFAIK, that's not possible, unless you where to overwrite an existing one because the size of the array is a #define.
Keep in mind there are user space changes required as well, at least if you want to be able to actually use the new system call.
Check The Linux Documentation Project website for "The Linux Kernel Module Programming Guide" (http://www.tldp.org/LDP/lkmpg/2.6/html/index.html). Specifically, look here for System Calls: http://www.tldp.org/LDP/lkmpg/2.6/html/x978.html. That should give you a start, at least.
This is an old question, but nevertheless I want to propose my solution. The easiest way to implement a "system-call-like" environment is to rely on a fake device.
In particular, you could create a new device driver which is not actually driving anything. Yet, writing on it, can cause the installed module to perform the required actions.
Additionally, if you want to offer several services, you might map them to ioctl operations.