Who knows where the source code VOP_WRITE_APV() in FreeBSD? How to append to the file automatically, without calculating the offset using the vn_rdwr(9) in FreeBSD?
These calls are generated from kern/vnode_if.src. The generated file is under the obj tree in kernel dir under the name vnode_if.c
Related
I wanted to call a C function defined in arm-tf (arm trusted firmware) from a u-boot assembly code. That assembly code of u-boot is arch/arm/lib/gic_64.S. The build process for this doesn't work out as I wanted so I ask it here with simple example.
In u-boot build tree, there is the directory arch/arm/lib. I added a directory arch/arm/lib/testd and put testf.c there. testf.c is just printing a string. In arch/arm/lib/Makefile, I added
libs-y += arch/arm/lib/testd
and in arch/arm/lib/testd/Makefile, I added
obj-y += testf.o
When I do make in u-boot root directory, I find nothing is made under arch/arm/lib/testd. But if I do make arch/arm/lib/testd/testf.o, that file is made. I saw this question but it doesn't help. Actually I guess I should see spl/arch/arm/lib/testd/{built-in.o, testf.o} if it was successful(because I'm building u-boot-spl).
I will be very grateful if anyone could tell me how I should do it. Thanks!
It looks like, if I add in arch/arm/lib/Makefile only
obj-y += testd/
Then by doing make I see arch/arm/lib/testd/testf.o and spl/arch/arm/lib/testd/{build-in.o,testf.o} generated.
The key part was the testd/ not testd.
I use an sh script to start an application in the background after setting several environment variables. I use temporary variables to start binaries from different places using LD_LIBRARY_PATH and temporary variables. Problem is that the application loads one *.so file from a hardcoded path which I cannot change. Currently I solve this problem manually by replacing the hardcoded file location with a symbolic link.
Can you tell me if there is a clean solution to solve this from the sh script? Basically what I want is that a certain file location is switched with a different binary only for open calls from the application the script starts, for all other processes it should stay the same.
Regards.
Example methods to replace open("/the/original") with open("/some/other"):
One simple method is modifying a pathname within an executable.
First copy the original executable to something like "modified" and run
a utility like bvi (similar to vim).
Consider 2 cases from comparing the length of the new vs. original pathnames:
when (new-length <= original-length), overwrite the original pathname in place
when (new-length > original-length), create a short symlink that references
the new longer pathname like the example below, then overwrite the original pathname
with the short symlink pathname,
ln -s /full/path/some/new/file /shorter
For both cases, remember to include a trailing NULL byte.
After saving changes with bvi, test the newly copied+altered executable.
Once "modified" is working to plan, could also rename for convenience:
mv xyz xyz.orig
mv modified xyz
Another method can serve a transparency requirement.
Create a dynamic library (eg custom.so) with a wrapper routine for
open() which conditionally replaces the pathname and calls the real
libc open(). Run the unmodified original executable (xyz) with another
environment variable, eg:
LD_PRELOAD=/path/to/custom.so xyz
There are some tradeoffs with versatility and modest complexity;
the original xyz is left unchanged and can always be run with/without LD_PRELOAD;
some might consider added overhead from a wrapper as undesirable;
doesn't work with statically-linked or set-uid executables.
Many articles provide instructions for creating a preload library, re-using
an original symbol like open() (frequent example is malloc()), call dlsym() once to find the regular libc open(), saving the result as a function pointer, and calling libc open() indirectly.
I have an open std::fs::File, and I want to get it's filename, e.g. as a PathBuf. How do I do that?
The simple solution would be to just save the path used in the call to File::open. Unfortunately, this does not work for me. I am trying to write a program that reads log files, and the program that writes the logs keep changing the filenames as part of it's log rotation. So the file may very well have been renamed since it was opened. This is on Linux, so renaming open files is possible.
How do I get around this issue, and get the current filename of an open file?
On a typical Unix filesystem, a file may have multiple filenames at once, or even none at all. The file metadata is stored in an inode, which has a unique inode number, and this inode number can be linked from any number of directory entries. However, there are no reverse links from the inode back to the directory entries.
Given an open File object in Rust, you can get the inode number using the ino() method. If you know the directory the log file is in, you can use std::fs::read_dir() to iterate over all entries in that directory, and each entry will also have an ino() method, so you can find the one(s) matching your open file object. Of course this approach is subject to race conditions – the directory entry may already be gone again once you try to do anything with it.
On linux, files handles held by the current process can be found under /proc/self/fd. These look and act like symlinks to the original files (though I think they may technically be something else - perhaps someone who knows more can chip in).
You can therefore recover the (possibly changed) file name by constructing the correct path in /proc/self/fd using your file descriptor, and then following the symlink back to the filesystem.
This snippet shows the steps:
use std::fs::read_link;
use std::os::unix::io::AsRawFd;
use std::path::PathBuf;
// if f is your std::fs::File
// first construct the path to the symlink under /proc
let path_in_proc = PathBuf::from(format!("/proc/self/fd/{}", f.as_raw_fd()));
// ...and follow it back to the original file
let new_file_name = read_link(path_in_proc).unwrap();
I am pretty new to linux kernel.I am trying to generate PWM through linux. The API man talks about a sysfs interface. I want to implement a userspace program in C. But using PWM forces me to use a command line. Furthermore, using read, write is a problem in C as when I am using cd, it is changing path directory.
Thus the path is variable. Is there any way I can pass values to pwm_config() without using sysfs? Perhaps through ioctl? If yes, then what would be the procedure?
Application C code:
void main(){
int export = open("/sys/class/pwm/pmwchip0/export",O_WRONLY);
int period,duty_cycle,enable;
if(export == -1)
{
perror("Export:");
}
and so on for other files like period and duty cycle.
When I try to run my application I get the following error.
Export:: No such file or directory
Export_write: Bad file descriptor
Period_write:: Bad file descriptor
Duty_cycle_write:: Bad file descriptor
Enable_write:: Bad file descriptor
As far as I know, the sysfs is the only standard userspace interface to PWM. But anything you can do from the command line can be done in C (the shell is written in C, after all).
The problem you are having with cd is not actually a problem. Inside sysfs the directories in /sys/class/pwd/* are actually symbolic links to the proper devices. In your case /sys/class/pwm/pwmchip0 is a symlink to /sys/devices/soc0/amba/f8001000.timer/pwm/pwmchip0.
The funny thing is that some shells, when you cd a symbolic link will resolve to the real directory, but other shells will actually keep the symlink name as the current directory.
But that issue with the directory symlinks should not be an issue for you. A C program willing to manage PWM devices should not change the working directory. Instead open the files with the full path:
open("/sys/class/pwm/pwmchip0/npwm", O_RDONLY);
and so on.
hi all:
recently i'm working on make checkpoint on linux process and encountered a problem,it looks like that when i munmap memory map of the executable to current process,the symlink /proc/self/exe is dead.what i want is to make this symlink pointing to a other executable(the one for my resumed processs),is that possible?i tried delete it and recreate, permission denied. english is not my native language, i hope i've made my point,thanx
prctl(PR_SET_MM_EXE_FILE, ...)
Supersede the /proc/pid/exe symbolic link with a new one pointing to a new executable file identified by the file descriptor provided in arg3 argument. The file descriptor should be obtained with a regular open(2) call.
No. /proc is completely managed by the kernel and does not allow changes like that.
But you may be able to start a new process (with fork() perhaps) and map your memory snapshot into that.