0

I'm making a device driver. I've added code that is most relevant to read and llseek. I can enter and use read perfectly fine. But for some reason, llseek can't be entered. I have it listed in the file operations as llseek and match it to the function I want, the arguments appear to be good?

In dmesg, i get "inside READ" but no "inside SEEK" and no errors. Also no errors in terminal, or during compilation. I don't know c too well either.

main

int file = open("/dev/simple_char_driver", O_RDWR);

//read example, this works fine
printf("Enter how many bytes you want to read: \n");
int len[10];
scanf("%d", len);
char *ptr = malloc(*len * sizeof(char));

read(file, ptr, *len);

//llseek example, doesn't enter
int offset [10];
int whence [10];
scanf("%d",offset);
printf("Enter a value for whence: \n");
scanf("%d",whence);

llseek(file, offset, whence); 

In my device driver:

loff_t simple_char_driver_seek (struct file *pfile, loff_t offset, int whence)
{
    printk(KERN_ALERT "Inside SEEK");
    return 0;
}

ssize_t simple_char_driver_read (struct file *pfile, char __user *buffer, size_t length, loff_t *offset)
{
    printk(KERN_ALERT "Inside READ");
    return 0;
}

struct file_operations simple_char_driver_file_operations = {

    .owner   = THIS_MODULE,
    .open    = simple_char_driver_open,
    .release = simple_char_driver_close,
    .read    = simple_char_driver_read,
    .write   = simple_char_driver_write,
    .llseek  = simple_char_driver_seek,
};
grilam14
  • 47
  • 1
  • 9
  • 2
    I'm rusty on kernel drivers, but could it simply be a case of missing '\n' at end of your printk calls? Have you tried debugging with strace? – visibleman Oct 04 '18 at 05:22
  • 1
    Also, I assume simple_char_driver_read , and simple_char_driver_seek has return statements? – visibleman Oct 04 '18 at 05:32
  • yes there are return statements, I took out a lot of the code to simplify it. I'll add the return statements but they came with the skeleton code and likely aren't the problem. I'm also trying to figure out how to debug. – grilam14 Oct 04 '18 at 05:36
  • 1
    You are right, If you have skeleton return statements, they are unlikely the problem. I remember buffering under printk being un-intuitive, so perhaps trying some extra new lines ('\n'), or even extra printk statements to force a flush will be helpful. Running under strace (man strace) traces system calls and signals, so it might help you see what is going on. – visibleman Oct 04 '18 at 05:40
  • any clue on strace ?? – asio_guy Oct 04 '18 at 06:04
  • 1
    Possible duplicate of [Why printk doesn't print message in kernel log(dmesg)](https://stackoverflow.com/questions/38822599/why-printk-doesnt-print-message-in-kernel-logdmesg) – Tsyvarev Oct 04 '18 at 08:07

1 Answers1

1

Regarding your second issue:
printk is line buffered. This means that the buffer will be flushed (contents will be sent to the logfile) upon encountering a newline character (\n). Otherwise, it will be done only when the program exits.
So use '\n' in your printk statements.

P.W
  • 26,289
  • 6
  • 39
  • 76
  • I just added \n to all of them, it still isn't reaching llseek – grilam14 Oct 04 '18 at 05:54
  • 1
    Are you able to print `whence` after reading into it with `scanf`? – P.W Oct 04 '18 at 05:57
  • OH, i forgot those variables were still pointers, they should've been sent as *offset and *whence. Those two variables were the only things that I didn't end up printing of course. It works. – grilam14 Oct 04 '18 at 06:05