Could you post some examples how to read list of meanings from /proc files?
list_head* get_from_proc_file()
{
struct file* file = fopen("example","r");
seq_open(file, &seq_ops);
struct seq_file *p = file->private_data;
READ LIST OF DATA?????
}
You can't use fopen as this is a libc function. The example bellow shows how to read a file from the kernel.
http://www.wasm.ru/forum/viewtopic.php?pid=467952#p467952
Probably you don't need to read a /proc file within kernel, because a /proc interface is used by kernel to export some information to user-space, the information definitely already exists in kernel, either in some list of struct's or other global containers. So the proper way is probably just getting the global list/container by calling some kernel API or using them directly, if they are exported.
Related
I want to save some information in a kernel module. I have seen similar question to mine here in stackoverflow, however mine is slightly different. Assuming I am using this code to write in a /proc file. How should I call it inside one of my kernel module? I have a custom kernel module called mymodule which is not the main file (does not have init_module()) inside it the below function is called. In this case what should be the input value to the function like value of file? Basically is it possible to create a /proc file inside a kernel module?
int procfile_write(struct file *file, const char *buffer, unsigned long count,
void *data)
It is definitely possible to add a proc entry in a kernel module but you might be misunderstanding how file handling works in the kernel.
When you create a file in proc, you're not actually 'creating' a file like you would in userspace. You're registering a few callbacks that are called when userspace programs request your file.
That means, when userspace programs request a read, your file read callback has to provide data. When a userspace program requests a write, your file write callback has to handle it.
If you want to use it like a conventional file to store information, you have to allocate the required space and have your read callback copy data from there.
Is there a function (or interface; ioctl, netlink etc) in the standard Linux libs that will return the current mounts directly from the kernel without parsing /proc? straceing the mount command, it looks like it parses files in /proc
Please see the clarification at the bottom of the answer for the reasoning being used in this answer.
Is there any reason that you would not use the getmntent libc library call? I do realize that it's not the same as an 'all in one' system call, but it should allow you to get the relevant information.
#include <stdio.h>
#include <stdlib.h>
#include <mntent.h>
int main(void)
{
struct mntent *ent;
FILE *aFile;
aFile = setmntent("/proc/mounts", "r");
if (aFile == NULL) {
perror("setmntent");
exit(1);
}
while (NULL != (ent = getmntent(aFile))) {
printf("%s %s\n", ent->mnt_fsname, ent->mnt_dir);
}
endmntent(aFile);
}
Clarification
Considering that the OP clarified about trying to do this without having /proc mounted, I'm going to clarify:
There is no facility outside of /proc for getting the fully qualified list of mounted file systems from the linux kernel. There is no system call, there is no ioctl. The /proc interface is the agreed upon interface.
With that said, if you don't have /proc mounted, you will have to parse the /etc/mtab file - pass in /etc/mtab instead of /proc/mounts to the initial setmntent call.
It is an agreed upon protocol that the mount and unmount commands will maintain a list of currently mounted filesystems in the file /etc/mtab. This is detailed in almost all linux/unix/bsd manual pages for these commands. So if you don't have /proc you can sort of rely on the contents of this file. It's not guaranteed to be a source of truth, but conventions are conventions for these things.
So, if you don't have /proc, you would use /etc/mtab in the getmntent libc library call below to get the list of file systems; otherwise you could use one of /proc/mounts or /proc/self/mountinfo (which is recommended nowadays over /proc/mounts).
There is no syscall to list this information; instead, you can find it in the file /etc/mtab
I was asked this question in an interview. You are writing a PCI driver and you want to export the hardware-related information to the /proc filesystem. The interesting thing is that I searched the driver code and I couldn't find any call related to /proc filesystem though actually the information is exported. Is it done automatically? What is the mechanism? Can anyone please explain?
Creating entries in the /proc pseudo-filesystem is explained in Linux Device Drivers [3rd ed], chapter 4.
Nowadays you probably want to consider using sysfs instead; it's covered in LDD3 chapter 14.
One way to do it is for your driver to
implement a function that will get called whenever a process reads the corresponding /proc entry with the following signature:
int (*read_proc)(char *page, char **start, off_t offset, int count, int *eof, void *data);
register your function by passing its pointer to create_proc_read_entry(), which accepts the name of the /proc entry as a string among other things:
create_proc_read_entry("foobar", 0, NULL, your_read_func_ptr, NULL);
When your driver unloads, it should remove the entry with remove_proc_entry()
In reference to linux kernel, I would like to access the "file" structure information like current file offset in a user space C program. How do I do it?
Thanks in advance
Is "in reference to linux kernel" relevant, or misleading information? That is, are you asking about the kernel-level open file description and its status, or the C library-level FILE * used in stdio? Either way, you cannot poke at the internals yourself. There are accessor functions you can use: ftello(f) for stdio, or lseek(fd, 0, SEEK_CUR) for file descriptors.
You cannot access kernel structures in userspace.
In C when we open a file what happens?? As I know that the contents of the file is not loaded in the memory when we open a file. It just sets the file descriptor ? So what is this file descriptor then?? And if the contents of the file is not loaded in the memory then how a file is opened?
Typically, if you're opening a file with fopen or (on a POSIX system) open, the function, if successful, will "open the file" - it merely gives you a value (a FILE * or an int) to use in future calls to a read function.
Under the hood, the operating system might read some or all of the file in, it might not. You have to call some function to request data to be read anyways, and if it hasn't done it by the time you call fread/fgets/read/etc... then it will at that point.
A "file descriptor" typically refers to the integer returned by open in POSIX systems. It is used to identify an open file. If you get a value 3, somewhere, the operating system is keeping track that 3 refers to /home/user/dir/file.txt, or whatever. It's a short little value to indicate to the OS which file to read from. When you call open, and open say, foo.txt, the OS says, "ok, file open, calling it 3 from here on".
This question is not entirely related to the programming language. Although the library does have an impact on what happens when opening a file (using open or fopen, for example), the main behavior comes from the operating system.
Linux, and I assume other OSs perform read ahead in most cases. This means that the file is actually read from the physical storage even before you call read for the file. This is done as an optimization, reducing the time for the read when the file is actually read by the user. This behavior can be controlled partially by the programmer, using specific flag for the open functions. For example, the Win32 API CreateFile can specify FILE_FLAG_RANDOM_ACCESS or FILE_FLAG_SEQUENTIAL_SCAN to specify random access (in which case the file is not read ahead) or sequential access (in which case the OS will perform quite aggressive read ahead), respectively. Other OS APIs might give more or less control.
For the basic ANSI C API of open, read, write that use a file descriptor, the file descriptor is a simple integer that is passed onto the OS and signifies the file. In the OS itself this is most often translated to some structure that contains all the needed information for the file (name, path, seek offsets, size, read and write buffers, etc.). The OS will open the file - meaning find the specific file system entry (an inode under Linux) that correlates to the path you've given in the open method, creates the file structure and return an ID to the user - the file descriptor. From that point on the OS is free to read whatever data it seems fit, even if not requested by the user (reading more than was requested is often done, to at least work in the file system native size).
C has no primitives for file I/O, it all depends on what operating system
and what libraries you are using.
File descriptors are just abstracts. Everything is done on the operating system.
If the program uses fopen() then a buffering package will use an implementation-specific system call to get a file descriptor and it will store it in a FILE structure.
The system call (at least on Unix, Linux, and the Mac) will look around on (usually) a disk-based filesystem to find the file. It creates data structures in the kernel memory that collects the information needed to read or write the file.
It also creates a table for each process that links to the other kernel data structures necessary to access the file. The index into this table is a (usually) small number. This is the file descriptor that is returned from the system call to the user process, and then stored in the FILE struct.
As already mentioned it is OS functionality.
But for C file I/O most probably you need info on fopen function.
If you will check description for that function, it says :
Description:
Opens a stream.
fopen opens the file named by
filename and associates a stream with
it. fopen returns a pointer to be used
to identify the stream in subsequent
operations.
So on successful completion fopen just returns a pointer to the newly opened stream. And it returns NULL in case of any error.
When you open the file then the file pointer gets the base address(starting address)of that file.Then you use different functions to work on the file.
EDIT:
Thanks to Chris,here is the structure which is named FILE
typedef struct {
int level; /* fill/empty level of buffer */
unsigned flags; /* File status flags */
char fd; /* File descriptor */
unsigned char hold; /* Ungetc char if no buffer */
int bsize; /* Buffer size */
unsigned char *buffer; /* Data transfer buffer */
unsigned char *curp; /* Current active pointer */
unsigned istemp; /* Temporary file indicator */
short token; /* Used for validity checking */
} FILE;