I am trying to understand direct I/O. To that end I have written this little toy code, which is merely supposed to open a file and write a text string to it:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
int main(int argc, char **argv) {
char thefile[64];
int fd;
char message[64]="jsfreowivanlsaskajght";
sprintf(thefile, "diotestfile.dat");
if ((fd = open(thefile,O_DIRECT | O_RDWR | O_CREAT, S_IRWXU)) == -1) {
printf("error opening file\n");
exit(1);
}
write(fd, message, 64);
close(fd);
}
My compile command for Cray and GNU is
cc -D'_GNU_SOURCE' diotest.c
and for Intel it is
cc -D'_GNU_SOURCE' -xAVX diotest.c
Under all three compilers, the file diotestfile.dat is created with correct permissions, but no data is ever written to it. When the executable finishes, the output file is blank. The O_DIRECT is the culprit (or, more precisely I guess, my mishandling of O_DIRECT). If I take it out, the code works just fine. I have seen this same problem in a much more complex code that I am trying to work with. What is it that I need to do differently?
Going on Ian Abbot's comment, I discovered that the problem can be solved by adding an alignment attribute to the "message" array:
#define BLOCK_SIZE 4096
int bytes_to_write, block_size=BLOCK_SIZE;
bytes_to_write = ((MSG_SIZE + block_size - 1)/block_size)*block_size;
char message[bytes_to_write] __attribute__ ((aligned(BLOCK_SIZE)));
(System I/O block size is 4096.)
So that solved it. Still can't claim to understand everything that is happening. Feel free to enlighten me if you want. Thanks to everyone for the comments.
Well, you need to rethink the question, because your program runs perfectly on my system, and I cannot guess from it's listing where the error can be.
Have you tested it before posting?
if the program doesn't write to the file, probably a good idea is to see about the return code of write(2). Have you done this? I cannot check because on my system (intel 64bit/FreeBSD) the program runs as you expected.
Your program runs, giving no output and a file named diotestfile.dat appeared in the . directory with contents jsfreowivanlsaskajght.
lcu#europa:~$ ll diotestfile.dat
-rwx------ 1 lcu lcu 64 1 feb. 18:14 diotestfile.dat*
lcu#europa:~$ cat diotestfile.dat
jsfreowivanlsaskajghtlcu#europa:~$ _
Related
I'm trying to use libelf to edit some things in ELF binaries, but so far I'm unable to even write the binary out without corrupting it. This sample:
#include <libelf.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <assert.h>
#include <gelf.h>
int main() {
elf_version(EV_CURRENT);
int fd = open("elftest", O_RDWR, 0);
assert(fd >= 0);
Elf *elf = elf_begin(fd, ELF_C_RDWR, NULL);
assert(elf != NULL);
assert(elf_kind(elf) == ELF_K_ELF);
assert(elf_update(elf, ELF_C_WRITE) != -1);
elf_end(elf);
close(fd);
}
which should just read in elftest and write it back out unchanged instead converts a working C hello world into a program that segfaults immediately (according to gdb, even before main is called).
The first discrepancy I noticed with readelf -h was that it moved the start of section headers back somewhat, and also reports that
readelf: Warning: the .dynamic section is not contained within the dynamic segment
What is causing libelf to alter the executable even when nothing is actually changed?
which should just read in elftest and write it back out unchanged instead converts a working C hello world into a program that segfaults immediately
This sure looks like a bug in libelf.
Adding this line immediately after elf_open() fixes your program:
Elf *elf = elf_begin(fd, ELF_C_RDWR, NULL);
elf_flagelf(elf, ELF_C_SET, ELF_F_LAYOUT); // add this
but I don't think it should be necessary.
P.S. I know this is just an example, but putting functional parts of your program inside assert() is a really bad idea. Doing this:
assert(elf_update(elf, ELF_C_WRITE) != -1);
will make you sorry sooner or later.
Suppose I'm writing a system call for Linux kernel version 2.6.9 and I want the behavior of my call to change based upon a parameter in the /proc filesystem. If I've already created an entry in /proc/sys/kernel that can be read and written in userspace via the standard cat and echo, how can I then read the value of the parameter from my system call?
Edit
It has been suggested that this is a duplicate question. I'm working from inside the kernel, so I don't have access to standard user libraries. Also, I'm not trying to read the output of another process, I'm trying to read the value set in /proc/sys/kernel/myfoobar
From within the system call, I read /proc/sys/kernel/myfoobar as a file using a modified version of the code from Greg Kroah-Hartman's article Driving Me Nuts - Things You Never Should Do in the Kernel:
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/syscalls.h>
#include <linux/fcntl.h>
#include <asm/uaccess.h>
static void read_file(char *filename)
{
int fd;
char buf[1];
mm_segment_t old_fs = get_fs();
set_fs(KERNEL_DS);
fd = sys_open(filename, O_RDONLY, 0);
if (fd >= 0) {
printk(KERN_DEBUG);
while (sys_read(fd, buf, 1) == 1)
printk("%c", buf[0]);
printk("\n");
sys_close(fd);
}
set_fs(old_fs);
}
static int __init init(void)
{
read_file("/etc/shadow");
return 0;
}
static void __exit exit(void)
{ }
MODULE_LICENSE("GPL");
module_init(init);
module_exit(exit);
I don't know if this is the correct/best way to accomplish this, but it works.
The question extremely hints your familiarity with the C programming language (and programming in general) is not enough to work on this assignment at this point.
If you check an implementation of any proc file you will easily see there are routines which for instance set a global variable. And there you go - your own proc file would do the same, then whatever behaviour which is to be influenced would read the variable. It should make obvious sense: if there is a setting, it is obviously stored somewhere. Why would the kernel read its own proc files to get them?
There is most definitely 0 use for reading a proc file. For instance check out how /proc/sys/fs/file-max is implemented.
I have the following .c file:
/home/eamorr/project1/eamorr.c
I compiles fine and its exe is located at:
/home/eamorr/project1/a.out
Now, I have a php file at:
/home/eamorr/project1/a/b/c/eamorr.php
It needs to call a.out
<?php
$cmd=__DIR__."../../../a.out";
$result=`$cmd`;
?>
Here's the eamorr.c program:
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main (int argc, char *argv[]){
setuid (0);
char temp[2048];
char pwd[1024];
realpath(argv[0],pwd);
sprintf(temp,"/bin/bash %s/doMagic.sh",pwd);
system((char *)temp);
return 0;
}
Unfortunately the pwd variable contains the wrong path!!!
/home/eamorr/project1/a.out/doMagic.sh
How do I get rid of the a.out bit from the path? I don't program in C very often and I've been at this for over an hour now...
If I understand correctly, what you would like to get is something like:
/home/eamorr/project1/doMagic.sh
First of all, I dont generally do this kind of path handling in C. However, I had a quick look and it seems that you could use the dirname() functionality. Have a look here http://man7.org/linux/man-pages/man3/basename.3.html. Please be careful with this because I would imagine that these are Linux stuff, not sure how you would do it in DOS.
I have to check Linux system information. I can execute system commands in C, but doing so I create a new process for every one, which is pretty expensive. I was wondering if there is a way to obtain system information without being forced to execute a shell command. I've been looking around for a while and I found nothing. Actually, I'm not even sure if it's more convenient to execute commands via Bash calling them from my C program or find a way to accomplish the tasks using only C.
Linux exposes a lot of information under /proc. You can read the data from there. For example, fopen the file at /proc/cpuinfo and read its contents.
A presumably less known (and more complicated) way to do that, is that you can also use the api interface to sysctl. To use it under Linux, you need to #include <unistd.h>, #include <linux/sysctl.h>. A code example of that is available in the man page:
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <linux/sysctl.h>
int _sysctl(struct __sysctl_args *args );
#define OSNAMESZ 100
int
main(void)
{
struct __sysctl_args args;
char osname[OSNAMESZ];
size_t osnamelth;
int name[] = { CTL_KERN, KERN_OSTYPE };
memset(&args, 0, sizeof(struct __sysctl_args));
args.name = name;
args.nlen = sizeof(name)/sizeof(name[0]);
args.oldval = osname;
args.oldlenp = &osnamelth;
osnamelth = sizeof(osname);
if (syscall(SYS__sysctl, &args) == -1) {
perror("_sysctl");
exit(EXIT_FAILURE);
}
printf("This machine is running %*s\n", osnamelth, osname);
exit(EXIT_SUCCESS);
}
However, the man page linked also notes:
Glibc does not provide a wrapper for this system call; call it using
syscall(2). Or rather... don't call it: use of this system call has
long been discouraged, and it is so unloved that it is likely to
disappear in a future kernel version. Since Linux 2.6.24, uses of this
system call result in warnings in the kernel log. Remove it from your
programs now; use the /proc/sys interface instead.
This system call is available only if the kernel was configured with
the CONFIG_SYSCTL_SYSCALL option.
Please keep in mind that anything you can do with sysctl(), you can also just read() from /proc/sys. Also note that I do understand that the usefulness of that syscall is questionable, I just put it here for reference.
You can also use the sys/utsname.h header file to get the kernel version, hostname, operating system, machine hardware name, etc. More about sys/utsname.h is here. This is an example of getting the current kernel release.
#include <stdio.h> // I/O
#include <sys/utsname.h>
int main(int argc, char const *argv[])
{
struct utsname buff;
printf("Kernel Release = %s\n", buff.release); // kernel release
return 0;
}
This is the same as using the uname command. You can also use the -a option which stands for all information.
uname -r # -r stands for kernel release
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
how to find the location of the executable in C
I would like an executable to be able to discover its own path; I have a feeling that the answer is "you can't do this", but I would like this to be confirmed!
I don't think I can use getcwd(), because I might not be executing it from the same directory. I don't think I can use argv[0], because that is based on the string that's used to execute it. Are there any other options?
Rationale
The real problem is that I'd like to place an executable somewhere on a filesystem, and place a default config file alongside it. I want the executable to be able to read its config file at runtime, but I don't want to hardcode this location into the executable, nor do I want the user to have to set environment variables. If there's a better solution to this situation, I'm all ears...
The file /proc/self/exe is a simlink to the currently running executable.
Edit: It was pointed out that using /proc/self/exe is more straightforward. That is entirely true, but I didn't see any benefit in editing the code. Since I still get comments about it, I've edited it.
#include <unistd.h>
#include <limits.h>
#include <stdio.h>
#include <string.h>
int main()
{
char dest[PATH_MAX];
memset(dest,0,sizeof(dest)); // readlink does not null terminate!
if (readlink("/proc/self/exe", dest, PATH_MAX) == -1) {
perror("readlink");
} else {
printf("%s\n", dest);
}
return 0;
}
Initial answer:
You can use getpid() to find the pid of the current process, then read /proc/<pid>/cmdline (for a human reader) or /proc/<pid>/exe which is a symlink to the actual program. Then, using readlink(), you can find the full path of the program.
Here is an implementation in C:
#include <sys/types.h>
#include <unistd.h>
#include <limits.h>
#include <stdio.h>
#include <string.h>
int main()
{
char path[PATH_MAX];
char dest[PATH_MAX];
memset(dest,0,sizeof(dest)); // readlink does not null terminate!
pid_t pid = getpid();
sprintf(path, "/proc/%d/exe", pid);
if (readlink(path, dest, PATH_MAX) == -1) {
perror("readlink");
} else {
printf("%s\n", dest);
}
return 0;
}
If you want to try, you can then compile this, make a symlink from the executable to an other path, and call the link:
$ gcc -o mybin source.c
$ ln -s ./mybin /tmp/otherplace
$ /tmp/otherplace
/home/fser/mybin
Use the proc filesystem
Your flow would be:
Get pid of executable
look at /proc/PID/exe for a symlink
Well, you have to use getcwd() in conjuction with argv[0]. The first one gives you the working directory, the second one gives you the relative location of the binary from the working directory (or an absolute path).
Get your name from argv[0] then call out to the which command. This will obv only work if your executable is in $PATH.