Find the answer to your Linux question:
Results 1 to 5 of 5
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    number of arguments in write call


    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 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
    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
    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.
    First they ignore you,Then they laugh at you,Then they fight with you,Then you win. - M.K.Gandhi
    FOSS India Award winning ext3fs Undelete tool Online Linux Terminal

  6. #5
    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