I am trying to learn some concepts about the VFS in the Linux Kernel and I can't seem to find which call(s) are made when creating a new file. I am specially interested in knowing how to know if the folder the file is going to be created in is a valid folder. Could some one point in the direction of the system call(s) to create a new file?
P.S. I'm using kernel 3.4
If you're talking about user space (which I assume because you asked about system calls), then one of the easiest ways to determine which calls are invoked is to use the strace utility.
Here, I'm using the touch utility to create a file.
$ rm foo; strace touch foo
Looking at the resulting output where foo is referenced we see:
open("foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
This should give you some clues to dig down further.
Take a look at kernel sources: linux/fs/open.c. There is definition of sys_open() function (SYSCALL_DEFINE3(open,)...). AFAIK this function is called when you call open() from userspace.
Related
I need to create a system call function to get all child folders of the directory. But, I don't have any idea to do that. Can you give me some keywords or advice to implement that?
asmlinkage long sys_get_child_folder(char* path, char** child_folder);
I'm smelling a XY problem; what is the actual problem you're trying to solve?
Why the heck do you want to create a new system call for that? Just open the directory, enumerate all its entries and filter out those, that are not directory inodes. The canonical way to do this is to use the opendir function. https://linux.die.net/man/3/opendir
Also keep in mind that if you're writing code that's supposed to run inside the kernel, be aware that from inside the kernel, the ususal file system mechanisms are difficult to reach. The reason for that is, that filesystems spawn namespaces, which are depending on the task context; the only robust way to access files from within the kernel, is to have a userspace process open them and then hand the file descriptor to some kernel code. But this is strongly discouraged.
I'm trying to write a program, calcsize, that calculates the size of all sub directories. I want to create a cache of the result and only re-walk the directory if it has changed since the last time I've run the program.
Something like:
./calcsize
//outputs
/absolute/file/path1/ 1000 Bytes
/absolute/file/path2/ 2000 Bytes
I'm already walking the dirs with my own walk implementation because the built in go filepath.Walk is already calling Lstat on every file.
Is there any way to know if a directory or set of files has changed without calling Lstat on every file? Maybe a system call I'm not aware of?
In general, no. However you might want to look at: https://github.com/mattn/go-zglob/blob/master/fastwalk/fastwalk_unix.go
And using that data you can skip some of the stat calls, if you only care about files.
Whether, and how, this is possible depends heavily on your operating system. But you might take a look at github.com/howeyc/fsnotify which claims to offer this (I've never used it--I just now found it via Google).
In general, look at any Go program that provides a 'watch' feature. GoConvey and GopherJS's serve mode come to mind as examples, but there are others (possibly even in the standard library).
I want to write the code in kernel space to find all open file handles in the system and the process id which holdes those handles.
In user space we can do it using the utility "lsof". Similarly, i want the same in kernel space.
What's so great about Linux Kernel is that it's open source. If you want to understand how to implement something that is similar to lsof why not inspecting its' source code (I suggest the following implementation, from Android 4.2.2 source tree, at it is simplified and easier to understand) or straceing it to understand how the magic happens?
If you'll do so, at some point you'll encounter the following line
openat(AT_FDCWD, "/proc/<PID>/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
Which will hint you that for each PID that is running, procfs is able to print information about all open file descriptors that this process holds. Therefore, this is where I would start my research and journey through the code.
Writing an archival utility, I need to be able to read and write resource forks on Mac OS X file systems.
There used to exist FSOpenFork and related functions, but current documentation both online and included with Xcode (v7.1) does not even mention these functions any more.
Furthermore, functions such as GetEOF are not even available any more to 64 bit apps.
Which APIs are currently available for reading and writing resource forks? If you can, please provide the declarations for functions to open, read, write, close and inquire/set the EOF and current r/w offset.
Note: While I've added my own answer listing the replacement FS... functions, it would be nice if others could add more ways, such as using CFURL APIs or the named fork method (which uses a special file name, but I keep forgetting how that works).
You can open the resource fork as a regular file by appending /..namedfork/rsrc. (This is defined in <sys/paths.h> as _PATH_RSRCFORKSPEC.) Although ugly, it does enable shell activities to access the resource fork even if there not aware resource forks exist. Example:
ls -l myfile/..namedfork/rsrc
cp myfile/..namedfork/rsrc ...
The resource fork is also available as the com.apple.ResourceFork extended attributes. (This is defined as XATTR_RESOURCEFORK_NAME in <sys/xattr.h>.) In particular, f/getxattr() and f/setxattr() can read and write the resource fork. The _PATH_RSRCFORKSPEC hack is actually implemented in terms of extended attributes by the XNU kernel.
The header file "Files.h" lists the available FS... functions.
Here are a few replacements:
SetFPos -> FSSetForkPosition
GetEOF -> FSGetForkSize
FSRead -> FSReadFork
I am a beginner to kernel module programming. And using resources online (especially this tutorial) I have managed to write most of my driver.
The driver basically is a character device which maps different areas of SRAM into separate files. You can see the actual code here.
Right now I am able to successfully create 4 files under /dev and reading/writing the first file works too but the other 3 files do not work. I am using minor number to distinguish between the files and assign the starting address accordingly.
Questions:
Why are the other files not working?
Is there a better way to implement the module?
Thanks.
Line 141,
"if (cdev_add(&c_dev, first, 1) == -1)",
only applies the file_operations struct to the first device.
You should use MAXDEVICES instead of 1 here
On another note, the init code is messy (better use goto and not duplicate the cleanup for every function that can fail) and in some cases plain wrong (device_destroy() before any devices were created, resource leak in case you fail the create a device that isn't the first).
The entire file does not stand up to kernel coding conventions.