I know that eBPF program can be pinned to /sys/fs/bpf (default location of small bpffs. For example using bpftool :
$ bpftool prog load ./my_bpf.o /sys/fs/bpf/my_bpf
I was expecting that open("/sys/fs/bpf/my_bpf") would return me the value of file descriptor allocated for my_bpf by the kernel. But open() call just fails, I think it returns -EINVAL.
In this case, what is the purpose of pinning? How do I normally obtain fd of a BPF program, given that there might be lots of them currently loaded. I know that libbpf allows to retrieve fd from id, but what if I don't have an id either?
bpf(BPF_OBJ_GET, …) wrapped in bpf_obj_get() in libbpf provided by kernel returns fd of the pinned object. Path to pinned object is an argument to bpf_obj_get().
Related
I've got several USB to 422 adapters in my test system. I've used FTProg to give each adapter a specific name: Sensor1, Sensor2, etc. They will all be plugged in at power on. I don't want to hard code each adapter to a specific ttyUSBx. I want the drivers to figure out which tty it needs to use. I'm developing in C for a linux system. My first thought was to something like this in my startup code.
system("dmesg | find_usb.py");
The python script would find the devices since each one has a unique Product Description. Then using the usb tree to associate each device with its ttyUSBx. The script would then create /tmp/USBDevs which would just be a simple device:tty pairing that would be easy for the C code to search.
I've been told...DoN't UsE sYsTeM...use posix_spawn(). But I'm having problems getting the output of dmesg piped to my python script. This isn't working
char *my_args[] = {"dmesg", "|", "find_usb.py", NULL};
pid_t pid;
int status;
status = posix_spawn(&pid, "/bin/dmesg", NULL, NULL, my_args, NULL);
if(status == 0){
if(waitpid(pid, &status, 0) != -1);{
printf("posix_spawn exited: %i", status);
}
I've been trying to figure out how to do this with posix_spawn_file_actions(), but I'm not allowed to hit the peak of the 'Ballmer Curve' at work.
Thanks in advance
Instead of using /dev/ttyUSB* devices, write udev rules to generate named symlinks to the devices. For a brief how-to, see here. Basically, you'll have an udev rule for each device, ending with say SYMLINK+=Sensor-name, and in your program, use /dev/Sensor-name for each sensor. (I do recommend using Sensor- prefix, noting the initial Capital letter, as all device names are currently lowercase. This avoids any clashes with existing devices.)
These symlinks will then only exist when the matching device is plugged in, and will point to the correct device (/dev/ttyUSB* in this case). When the device is removed, udev automagically deletes the symlink also. Just make sure your udev rule identifies the device precisely (not just vendor:device, but serial number also). I'd expect the rule to look something like
SUBSYSTEM=="tty", ATTRS{idVendor}=="VVVV", ATTRS{idProduct}=="PPPP", ATTRS{serial}=="SSSSSSSS", SYMLINK+="Sensor-name"
where VVVV is the USB Vendor ID (four hexadecimal digits), PPPP is the USB Product ID (four hexadecimal digits), and SSSSSSSS is the serial number string. You can see these values using e.g. udevadm info -a -n /dev/ttyUSB* when the device is plugged in.
If you still insist on parsing dmesg output, using your own script is a good idea.
You could use FILE *handle = popen("dmesg | find_usb.py", "r"); and read from handle like it was a file. When complete, close the handle using int exitstatus = pclose(handle);. See man popen and man pclose for the details, and man 2 wait for the WIFEXITED(), WEXITSTATUS(), WIFSIGNALED(), WTERMSIG() macros you'll need to use to examine exitstatus (although in your case, I suppose you can just ignore any errors).
If you do want to use posix_spawn() (or roughly equivalently, fork() and execvp()), you'd need to set up at least one pipe (to read the output of the spawned command) – two if you spawn/fork+exec both dmesg and your Python script –, and that gets a bit more complicated. See man pipe for details on that. Personally, I would rewrite the Python script so that it executes dmesg itself internally, and only outputs the device name(s). With posix_spawn(), you'd init a posix_file_actions_t, with three actions: _adddup2() to duplicate the write end of the pipe to STDOUT_FILENO, and two _addclose()s to close both ends of the pipe. However, I myself prefer to use fork() and exec() instead, somewhat similar to the example by Glärbo in this answer.
I would like to know the mechanism in which the Linux Kernel knows which file descriptor (e.g. /dev/input/eventX) to write the input to. For example, I know that when the user clicks the mouse, an interrupt occurs, which gets handled by the driver and propagated to the Linux input core via input_event (drivers/input/input.c), which eventually gets written to the appropriate file in /dev/input/. Specifically, I want to know which source files I need to go through to see how the kernel knows which file to write to based on the information given about the input event. My goal is to see if I can determine the file descriptors corresponding to specific input event codes before the kernel writes them to the /dev/input/eventX character files.
You may go through two files:
drivers/input/input.c
drivers/input/evdev.c
In evdev.c, evdev_init() will call input_register_handler() to initialize input_handler_list.
Then in an input device driver, after initialize input_dev, it will call:
input_register_device(input_dev)
-> get device kobj path, like /devices/soc/78ba000.i2c/i2c-6/6-0038/input/input2
-> input_attach_handler()
-> handler->connect(handler, dev, id);
-> evdev_connect()
In evdev_connect(), it will do below:
1. dynamic allocate a minor for a new evdev.
2. dev_set_name(&evdev->dev, "event%d", dev_no);
3. call input_register_handle() to connect input_dev and evdev->handle.
4. create a cdev, and call device_add().
After this, you will find input node /dev/input/eventX, X is value of dev_no.
So I am supposed to achieve following behavior.
This project you are asked to add a new field to the task descriptor. The name and type of the field is: int casper;
If casper=0 : The process is visible to all, i.e. it is listed in the /proc file system and it can be seen using “ps”, “pstree”, “top”, ...
If casper=1 : The process is visible only to processes which have the same user id, i.e. for all other processes, it is NOT listed in the /proc file system and it can NOT be seen using “ps”, “pstree”, “top”, ...
If casper=2 : The process is visible only to processes which are in the same group, i.e. for all other processes, it is NOT listed in the /proc file system and it can NOT be seen using “ps”, “pstree”, “top”, ...
If casper=3 : The process is invisible for all, i.e. it is NOT listed in the /proc file system and it can NOT be seen using “ps”, “pstree”, “top”, ...
I have already modified task_struct definition and its default value for init process and added necessary stuff to fork sys call
I did some research but couldnt find an obvious way to do this. So I assumed that /proc is created per request so I can get the task_struct of the process that requested it and populate the /proc according to that. Am I on the right track?
Yes, it's. /proc is a vritual filesystem generated by the kernel upon request. Check the following article for more details: Linux VFS
Recently, I developed a simple file system kernel module.
So, I needed to assign my own ioctl function (.unlocked_ioctl) to the file_operation structure to implement specific commands to my file system module. The Ext4 file system has its own ioctl function, for example.
Then, I created a file using the dd command and mounted it:
# mount -t myfs -o loop simple_file /mnt/
Everything works fine, but how can I access this file system using ioctl with a user space program?
I tryed to do ioctl(fd, MY_COMMAND_1, &my_struct_t); (where fd is the file descriptor of the dev file /dev/loop[0..7]), but it returns me Invalid argument.
If you open /dev/loop0, you're accessing a loop device, and therefore you're talking to the loop driver.
The ioctl handler that you've registered for your filesystem applies to files opened on a mounted filesystem.
fd = open("/mnt/something", O_RDWR);
ioctl(fd, MY_COMMAND_1, &my_struct_t);
How can I get the PID of the user process which triggered my Kernel module's file_operation.read routine (i.e., which process is reading /dev/mydev) ?
When your read function is executing, it's doing so in the context of the process that issued the system call. You should thus pe able to use current, i.e. current->pid.
These days, we have some helper functions defined in sched.h. In the case of pid, you can use:
pid = task_pid_nr(current);
to get the current task's pid.
here is the comment taken from include/linux/sched.h as of v3.8.
the helpers to get the task's different pids as they are seen
from various namespaces
task_xid_nr() : global id, i.e. the id seen from the init namespace;
task_xid_vnr() : virtual id, i.e. the id seen from the pid namespace of current.
task_xid_nr_ns() : id seen from the ns specified;
set_task_vxid() : assigns a virtual id to a task;
see also pid_nr() etc in include/linux/pid.h
On a kernel 2.6.39 arm build, if current->pid does not work then it may be done by:
pid_nr(get_task_pid(current, PIDTYPE_PID))
The PIDTYPE_PID can be substituted by PIDTYPE_PGID or PIDTYPE_SID. The header source is at include/linux/pid.h as Yasushi pointed out.
Which of the approaches work depends on what header files the code uses.