I am working in omap4 based system. It has 4 UART port so kernel makes:
/dev/ttyO0
/dev/ttyO1
/dev/ttyO2
/dev/ttyO3
When I open from user space:
fd = open("/dev/ttyO1",O_RDONLY)
it succesfully open and i can peform read and write with that.
But when I open:
fd = open("/dev/ttyO3",O_RDONLY)
Its failed.
I am able to see /dev/ttyO3 node in my system still why i am not able to open it? Any idea?
i have given permission to that node and now i can open that node
chmod 0606 /dev/ttyO3
Related
int fd;
ssize_t w;
char i[35]="/sys/class/gpio/gpio";
strcat(i,a);
strcat(i,"/direction");
fd=open(i,O_WRONLY);
if(fd==-1){
perror("direction:");
return(-3);
It is the part of my code. I am writing a program for GPIO of Raspberry Pi using sysfs file access. I want to access this path by the above code but it was not opened and the error shown was Permission denied. How can I can access this file?
If you are not logged-in as the pi user (the default one), add your user to the "gpio" group. That would give you read/write/execute permissions to the GPIO files.
This is a newbie kernel module question... I have mymodule.c with a function:
static int mymodule_open(struct inode *inode, struct file *filp)
{
//printk(KERN_INFO "open called\n");
/* Success */
return 0;
}
and a user level program where the first line after variable initializations is:
FILE *pFile = fopen("/dev/mymodule", "r+");
When I run the user level program this fopen somehow calls the mymodule_open command in mymodule.c (compiled to mymodule.ko). How does it know to do this? I can't connect the dots as to how mymodule_open() knows when fopen opens up /dev/mymodule.
There is a module registration mechanism in kernel for device driver or kernel modules.
/dev/module will be linked with your module.
The Device operations and file operations structure is mapped with the device file.
something like
struct file_operations fops = {
open : my_module_open,
release : my_module_release,
ioctl : my_module_ioctl,
};
Device file will identify and open the module with help of major and minor number.First with device file and then file operations structure.
Also look into device registration and device file operations
The moment user space hits fopen call, it gets routed to open "system call" and from there to the corresponding/registered driver's fops-open call by identifying the major:minor number of the device file.
Every Device file has got a "major:minor" tuple to belong to a particular driver, and corresponding fops structure will have the supported operations declared/defined.
fopen(/dev/mymodule) -> library_function(open, file_arguments) ->
systemcall(open, file_arguments) -> filesystem_driver(inode, open,
more_arguments) -> filesystem_driver(major:minor, open,
more_arguments) -> fops_structure (open, more_arguments)
NOTE: Above names are for explanation of flow of reach from fopen to mymodule_open, other than that, the names are not absolute function names, viz., library_function, systemcall, filesystem_driver...
The driver knows about the /dev/mymodule file open, because it is a triggered event as mentioned in the above fashion, from fopen, each level of function starts triggering next level of function call, until reaches the ultimate function of mymodule_open inside driver
I am working on ubuntu.
I am trying to open /dev/mem and i am getting permission denied
int32_t open_memdev()
{
int32_t fd;
fd = open("/dev/mem", O_RDONLY);
if (fd < 0) {
printf("Failed to open /dev/mem : %s\n", strerror(errno));
return-EINVAL;
}
return fd;
}
This code always prints "Failed to open /dev/mem : Operation not permitted"
I have searched for this on SO
access-permissions-of-dev-mem
accessing-mmaped-dev-mem
These q's seem to discuss the issue of not being able to access above 1 MB, but my problem is that i am unable to open even once.
Addtitional details if they help:
1) I checked my configuration that CONFIG_STRICT_DEVMEM is enabled.
2) ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 2014-03-13 13:57 /dev/mem
Please let me know if additional information is required.
You cannot read /dev/mem if you are not root.
There is no reason for an ordinary application to access /dev/mem, i.e. the physical RAM, since applications are running in virtual memory !
If you change the permission of /dev/mem to enable that (you should not), you will open a huge security hole in your system. Only trusted root processes should access /dev/mem. See mem(4)
(you could use setuid techniques if so wanted, or run your program with sudo)
If you need to access virtual memory in the address space of some other process, consider proc(5) e.g. /proc/1234/mem for process of pid 1234.
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);
I have a program that is listening to a certain event file handle. Is there a file I can read to get details about the specific event's device that I am listening to?
Assuming that (a) you're on Linux and (b) you have sysfs mounted (typically on /sys), you can look at /sys/class/input/eventX. This will be a symlink into the device tree; this should provide you some device details. For example:
$ readlink /sys/class/input/event4
../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.1/input/input4/event4
For USB devices, you could then probably mount a usbfs filesystem and check out the devices file for more information.
Do you have access to the file descriptor or is this an external program? If this is your fd to the actual device, a list of ioctls provides you with most info you'll need. Have a look at print_device_info from evtest, it does exactly that:
http://cgit.freedesktop.org/evtest/tree/evtest.c#n753