Find the answer to your Linux question:
Results 1 to 5 of 5
Hi, Can anyone explain this to me - or is something wrong with the code I am looking at ... I am looking at the source of an application that ...
  1. #1
    Just Joined!
    Join Date
    Mar 2009

    number of arguments in write call



    I am looking at the source of an application that is making use of an I2C device driver. In order to perform a 'write' it is calling the following function with three arguments.

    write(fd, buf, 1);
    where fd is the file handle to the device, buf is the data buffer containing the bytes to write and the last argument is the number of bytes to write.

    The driver source code in the kernel assigns the following function in the i2cdev_fops structure.
    static struct file_operations i2cdev_fops = {
        .owner      = THIS_MODULE,
        .llseek     = no_llseek,
        .read       = i2cdev_read,
        .write      = i2cdev_write,
        .ioctl      = i2cdev_ioctl,
        .open       = i2cdev_open,
        .release    = i2cdev_release,
    But the i2cdev_write function appears to have four arguments ...

    static ssize_t i2cdev_write (struct file *file, const char __user *buf, size_t count, loff_t *offset)
    The code appears to work okay - so how does this fourth argument loff_t *offset pick up a value when the call from user space only passed in three arguments?

    The user space application is also passing in an int as a file descriptor - but the i2cdev_write expects a struct file * ... ?

  2. #2
    Just Joined!
    Join Date
    Jun 2006
    write(fd, buf, 1); is s system call
    int fd= open("i2cdev" , O_RDWR, 077);

    open() will provide all information into fd, fd is handled by filesystem.

    you can't access driver write() fn directly because that lies in kernel space, here u need a system call (write()) to communicate with ur driver write function.

  3. #3
    Just Joined!
    Join Date
    Mar 2009
    Thanks for the reply ashok449.

    I'm fiddling with the kernel space device driver as well as the user space application making the system call.

    I think I have realised what I didn't understand before. I was assuming that there was a direct link somehow between the user space system call write and the kernel space fops structure member .write and therefore got confused why the number of arguments in those two functions didn't match up.

    In reality there must be quite a lot going on behind the scenes - calling the write function with four arguments will get handled by the file system as you say and after it does what ever it does will result in a call to the .write function pointer.

  4. $spacer_open
  5. #4
    Linux Guru Lakshmipathi's Avatar
    Join Date
    Sep 2006
    3rd rock from sun - Often seen near moon


    I'm don't know the answer as I'm not a device driver programmer, if you not aware "Linux Device Drivers" By Alessandro Rubini wil be very helpful.
    FOSS India Award winning ext3fs Undelete tool Online Linux Terminal

  6. #5
    Just Joined!
    Join Date
    Mar 2009
    I've got it, and yes it is very helpful.

    I've got what I need working now, but it would still be interesting to be directed towards the source that shows what goes on between the file system call and the link to the kernel space function pointer mentioned above.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts