I have a piece of C code which with a chunk of memory(static array) can mimic file operations (It has APIs similar to fopen/fclose etc). So, any code that is compiled with this mimicking FileSystem can use these APIs as a FileSystem for all their needs :)
But I was wondering, if its possible somehow to register these APIs with Linux system/mouning this File system, and hence enabling any client to use this FS by using normal FileSystem calls (without any need of statically linking it with the My_FileSystem).
While searching for a solution, I came across this idea of making my_FileSystem as a Driver!!! =>
Is it possible to compile my code as a device driver (with the memory chunk in the driver) and mount this File_system # say "/mnt/MyFs", and divert FileSystem calls like USB drivers do? (If this can be done, can you please explain how its done or point me to somewhere I can read about this).
I don't want to add these as new System calls and recompile the kernel (And making life of ppl wanting to use this difficult).
This is mainly for embedded systems running Linux... But other suggestions are also welcome. :)
Thank You,
MicroKernel :)
Look at FUSE (Filesystem in Userspace), especially on examples. Its quite easy...
Take a look at tmpfs and ramfs. These already ship with Linux and do all that you're trying to do and more. I don't think either of them would be too expensive for an embedded system.
I would consider PlasticFS, but that will work reliably only if everything uses system C library (i.e. no statically linked binaries).
Related
As the title has said, I'm looking for how I can read/write blocks directly to disk in linux kernel space (bypassing the file system) and directly interact with block IO layer.
After reading through some kernel codes, I realize bio is the structure I should be using to achieve such goal in block IO layer. But I don't quite understand the structures of bio and haven't figure out how exactly I can do that.
Any helps? Thank you
If you're only doing something simple, you don't really need to mess with BIO. What you can do instead is to simply open the block device (/dev/whatever) as if it was a file. The kernel will do the right thing and will give you the "thin" wrapper for read/write operations.
In regard to opening the file from the kernel space, there are few questions here, already answered, like this one:
How to read/write files within a Linux kernel module?
If you want to do anything more fancy, you will have to study the sources of the FS drivers (in the fs/ subdirectory) to hunt for examples.
In case anyone is interested in doing this with Node.js, we released a native add on yesterday with helpers for opening and working with block devices: https://github.com/ronomon/direct-io
I'd like to learn about proc and sysfs entries.
So far, what I have understood is that, proc entries are the values which is set to proc file system. I'm not sure whether I'm correct. Could anyone explain it in detail about its real need and where it is used? Please provide me links to know it better. Any kind of guidance is accepted.
The /proc filesystem is a special, software-created filesystem that is used by the kernel to export information to the world. Each file under /proc is tied to a kernel function that generates the file's "contents" on the fly when the file is read. We have already seen some of these files in action; /proc/modules, for example, always returns a list of the currently loaded modules.
/proc is heavily used in the Linux system. Many utilities on a modern Linux distribution, such as ps, top, and uptime, get their information from /proc. Some device drivers also export information via /proc, and yours can do so as well. The /proc filesystem is dynamic, so your module can add or remove entries at any time.
Fully featured /proc entries can be complicated beasts; among other things, they can be written to as well as read from. Most of the time, however, /proc entries are readonly files. This section concerns itself with the simple read-only case. Those who are interested in implementing something more complicated can look here for the basics; the kernel source may then be consulted for the full picture.
Before we continue, however, we should mention that adding files under /proc is discouraged. The /proc filesystem is seen by the kernel developers as a bit of an uncontrolled mess that has gone far beyond its original purpose (which was to provide information about the processes running in the system). The recommended way of making information available in new code is via sysfs. As suggested, working with sysfs requires an understanding of the Linux device model, however, and we do not
source - http://tjworld.net/books/ldd3/#UsingTheProcFilesystem
u can look at the ldd3 for more detailes.
it is often used as a tool for debuging the device drivers.
i am a newbie.
good luck.
I was wondering if anyone knows a way to prevent building unneeded device drivers when building the 2.6.32 kernel in Ubuntu 10.4 on VB? The reason I ask is we have to do a project for my operating systems class that involves adding some system calls to the kernel and the instructions say that after you add your call you need to rebuild the kernel(which takes like 3 freakin hours) and I know its because Ubuntu doesn't know which device drivers I need on so it builds them all so I'm wondering if there is a way to have it only build the ones I need? and if so how to go about that? or if anyone knows a way of being able to test added system calls without rebuilding the whole kernel(as this is really the issue)?
Thanks in advance
You can manually change kernel configuration with with rather friendly menus. Just type make nconfig (or menuconfig, or xconfig for gui). And remove drivers that you don't need.
Here are some links that may help you:
http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch05.html
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7
http://kernel.xc.net/
Also, do you have a multicore processor? If so do you use advantages of it like here?
UPDATE: I've remembered a faster way. You can wrap a new syscall in module, thus avoiding recompilation of the whole kernel. Look here and there.
You can easily find everything here with the help of Google, though.
I'm working an a system with embedded Linux (Kernel 2.6.31).
It is a AT91SAM9G20 chip inside, and some of the Pins are forwarded to the outside.
Now I want to use them as GPIO Inputs.
I read the gpio.txt documentation about using the GPIOs via filesystem, and that works very well 'til here. I connected some switches to the gpio-pins and I can see the result in /sys/class/gpio/gpioX/value. But now I'd like to react on a change without busy-waiting in a loop. (i.e echo "Switch1 was pressed").
I guess I need interrupts here, but I couldn't find out how to use them without writing my own kernel driver. I'm relatively new to Linux and C (I normally program in Java), so I'd like to handle the Interrupts via sysfs too. But my problem is, that there is no "edge"-file in my GPIO directory (I guess because this is only since Kernel version 2.6.33+). Is that right? Instead of "edge" I've got a uevent file in there, which is not described in gpio.txt.
In the gpio.txt documentation there was a Standard Kernel Driver mentioned: "gpio_keys". Is it possible to use this for my problem?
I guess it would be better to work with this driver than allowing a userspace program to manipulate kernel tasks.
I found a lot of codesnippets for writing my own driver, but I wasn't even able to find out which of the 600 gpio.h files to include, and how to refer to the library (cross compiler couldn't find the gpio.h file).
Sorry for newbie questions, I hope you could give me some advices.
Thanks in advance
See this for an example on how to do that. Basically, the thing you're missing is the usage of the select or poll system calls.
I'm writing a patch for VFS FAT implmentation on kernel 3.0
I want to add posix attributes to FAT files that are created in linux.
to achive that, I must save a file that contains all the relevant information on the mounted drive.
I know that reading and writing files from kernel space is something normally shouldn't be done, and I'm looking for another way to read/write the data.
I saw articles on the net that suggested to use /proc or to create a userspace daemon that will do the IO for me. I wanted to know if anyone saw or know where can I look at an implmentation of a thing like that,because I didn't find any examples for that over the net.
I'm not looking for a read/write to proc example, I want to see an entire solution for this issue.
Have a look at the quota implementation; this is a mechanism (ok, presumably not available on vfat) which reads/writes files from the kernel.
Additionally, the "loop" block device is another example of a kernel facility which does file IO.