Does read() causes the kernel device driver code to be executed? - operating-system

Does read() system call causes the kernel device driver code to be executed?
I mean, when I want to read files from disk or from any driver, I use read() system call. Is that system call must use driver code to complete this task?
Thanks.

Yes, the read() uses standard file descriptors to read files from fixed offsets in files and of fixed bytes. The standard file descriptors are not files on the disc, but rather associated with a different device, the terminal device. Hence the drivers must be in use for the files to be accessed.
See man read for its usage and C prototype.
For more info about file handling use this link, particularly the "Reviewing Open Files" section for your particular query.

Related

INode File System, what is the extra space in a data block used for?

So, I am currently learning about the INode file system and am asked to write a simple file system using Inodes.
So far, I understand that there is an INode table that has a mapping from INode-> Data blocks through direct/indirect pointers.
Let's assume data gets written into a file, the data is stored into two blocks. Let's say each block is 512bytes, and the file takes one full block, and only 200 bytes of the second block. What happens with the rest of the space in that data block? Is it reserved for that file only or do other files use this block?
Depending on the file system, usually and most likely this area is now lost. I think the Reiser File System actually reclaimed this area, but I could be wrong.
Creating your own File System can be a challenging experience, but also an enjoyable experience. I have created a few myself and worked on another. If you are creating your own file system, you can have it do whatever you wish.
Look at the bottom of this page for a few that I am working on/with. The LeanFS in particular, uses Inodes as well. The SFS is a very simple file system. Each is well documented so that you can research and decide what you would like to do.

How to open file for writing in shared mode in Perl

I would like to open file in shared mode for editing (other processes must have access to that file for writing as well) under Windows OS. Is it possible in Perl?
For example, in WinApi there is a possibility to specify flag FILE_SHARE_WRITE in CreateFile() function.
Thank you!
Multiple processes writing to the same file is a bad situation. An example would be a database scenario where a table must be locked by a processes in order to changes to be written to the table reliably. You could write something that does nothing else but listen to the other processes to write to the file.
perlmonks suggest using flock
Here's the link. Hope this helps!

Can I assume an executable file as a snapshot image of an execution state?

I read some unix manual (http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html), and there was a mention about execution.
The new process image shall be constructed from a regular executable
file called the new process image file.
The expression process image caught my eyes.
I have been thought executable file is just a kind of sequence of command. Just as the word program means. But actually, I don't know the concept and structure of the executable file. And I felt executable file could be looks like an execution state image from the mention.
Could you explain me something about this? About the concept and structure of regular executable files in nowadays. In any OS.
Usually the executable file does not contain only instructions but also global data, readonly data and many more. I suggest you briefly look e.g. on the ELF format widely used in UNIX-like operating systems or PE format used in Windows.
The OS may also need for example to replace some addresses of functions (jump targets) with the real addresses of these functions in the memory, although this technique is probably not used anymore in common OSes. Anyway, there can be more work to do than just copy the file into memory and start executing from the first byte.

file name for the open character special device file in driver code

In solaris when open call to char special device file is made in user space, the driver's open call is called with only two parameters. 1. major and minor number and 2. flag that contains read/write etc.. Is there any way to the get the name of the opened device file in driver's open call. or Is there any way to get the name of the device file from major and minor number in driver code?
I doubt the OS has any way to retrieve the name of the device file. Actually, this file name is not enforced by the OS and can be any name created with the mknod command. The only things that matter are the major and minor device numbers.
You can go through the lists of entries in /dev or /devices and compare the numbers. But of course in general, the special file could have been created anywhere in the filesystem.
But you shouldn't try doing this. Which problem are you trying to solve by this?

Hash of an .exe file

I'm wondering whether I will ever get a different result when producing a checksum on an .exe file before and then while or after running that file. I'm more concerned with common practice (such as producing a SHA hash of popular app like firefox.exe) than with boundary cases, but both are interesting. Thanks.
The hash of a file should be constant for as long as the file is identical (i.e. contains only the same bytes, in the same order). It's very rare to find applications that rewrite their on-disk representation at runtime, so the hash should be constant. There are self-modifying programs, but they tend to operate on the in-memory loaded copy of their code, rather than the disk copy.
Edit: We should consider "Self-updating" applications, but these tend to launch a little helper program to download and update the core application. It's difficult (especially on Windows) to update an execution whilst it's running. UNIX systems tend to operate Copy on Write systems, so it's possible that a software update might change your executable under your feet - but again, this is a "corner case".
The hash will only change if the exe changes. That will only happen if the app modifies itself, which isn't going to happen on windows without the app restarting. Firefox might update itself (including a restart), but apart from such cases, the hash will remain the same.
The hash will change if the file changes.
EXE files rarely change on their own. firefox.exe would change if the user updates to a new version.
You can check the "date modified" attribute of an EXE file (like firefox.exe) after running it to see whether it has changed, but you'll probably find it hasn't.
If you mean the modification of the last access time, don't worry, it's stored at the filesystem level, not within the file so the hash will remain the same.