Thread: Linux Kernel I/O C programming

  1. #1
    Registered User
    Join Date
    Feb 2009
    Posts
    7

    Linux Kernel I/O C programming

    Hello,

    I am working on a homework assignment that has to do with writing code for a ramdisk. I have most of it figured out, but I need to implement an extra feature. So what I have is a device info structure that has various fields and pointers to things, and I want to be able to access certain fields from the user space (i.e. outside the driver). This is proving to be very painful ( and impossible). My other alternative is to handle some prompts inside the device kernel code. I can print things onto my emulator, but I can't take any input, which is what I want to do. Long story short, I am wondering if there is any way to get input into the kernel. Something along the lines of fgets(), but that I can use in my device.

    Thank you for any thoughts you might wish to share.

    -George

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I'm not aware of any method to read stdin (in a reliable way) inside the kernel. I would also recommend that this is NOT the right way to do things.

    What are the actual things you need to do?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Feb 2009
    Posts
    7
    Thanks for the reply. I need to lock my devices with a password, and the only place I could think to store the password is in the device info structure. I was hoping to prompt the user for a pass from inside the device witch now seems like a bad idea.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I would have a service application that asks the user for the password, and then using a private IOCTL to pass the password to the device. In a real-world application, I'd expect "mount" to have this as part of it's functionality, but for a school/hobby project, just having a separate applicaiton that sends the password to the driver will be fine, I would.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Feb 2009
    Posts
    7
    I have considered this, but I can't pass the password to ioctl. I was actually thinking of doing all this nasty I/O inside the ioctl itself. I do have an access application but the ioctl function is as follows:

    int my_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg)

    an example of a call I do in the assignment from the access application is:

    ioctl(devfd, MYCOMMAND, NULL);

    I am thinking I need to pass char* to it but I don't know how.

    Thanks for the reply
    -George

  6. #6
    Registered User bboozzoo's Avatar
    Join Date
    Jan 2009
    Posts
    14
    Code:
    #define MAX_PASS_LEN 10
    struct device_pass_s {
      char pass[MAX_PASS_LEN];
    };
     
    /* then the ioctl call should be the following */
    struct device_pass_s pass = { 
        .pass = "mypass" 
    };
    
    ioctl(fd, SPASS, &pass);
    
    /* in kernel code */
    ioctl_handler(.... unsigned long arg) {
      struct device_pass_s pass;
      copy_from_user(&pass, (void *) arg, sizeof(struct device_pass_s));
      /* not sure about copy_from_user, haven't used that for quite some time, you might check if arg isnt' declared as unsigned long __user arg where __user (or sth similar) would indicate that the memory range is userspace */
    }

  7. #7
    Registered User
    Join Date
    Feb 2009
    Posts
    7
    Wonderful. Thank you. I will give it a try later today, it seems clear.

    If I'm not mistaken, I can use the long argument to pass a pointer?

    As far as copy_from_user, I think memcpy would do the trick, since I already used it in my code.

    Thanks again.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by inferno_gogo View Post
    Wonderful. Thank you. I will give it a try later today, it seems clear.

    If I'm not mistaken, I can use the long argument to pass a pointer?
    Yes, in Linux a long is the same size as a pointer.
    As far as copy_from_user, I think memcpy would do the trick, since I already used it in my code.

    Thanks again.
    Just to be flexible, you may want to add a size to the struct itself, and then validat the size before calling copy-from-user to allow:
    1. User passing a smaller password.
    2. future expansion.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Apr 2008
    Posts
    396
    Yes, in Linux a long is the same size as a pointer.
    it's true for 32-bits architectures, but 'long' is only required to be of at least 32-bits whereas sizeof(void*) is of 64-bits on a 64-bits arch, right? ...anyway ioctl can use another type for the argument I guess.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by root4 View Post
    it's true for 32-bits architectures, but 'long' is only required to be of at least 32-bits whereas sizeof(void*) is of 64-bits on a 64-bits arch, right? ...anyway ioctl can use another type for the argument I guess.
    But all of the exisitng 64-bit ports have 64-bit "long". AFAIK at least - I _KNOW_ this is true for x86_64, IA64 and Sparc64, and I'm pretty sure Alpha is too. You could add some code to do a runtime check that sizeof(void *) == sizeof(long) if you really want to make sure.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Feb 2009
    Posts
    2
    Hi, I literally have this exact same problem and I was wondering, how would I do this if I don't have an access application? I want to prompt for a password immediately on starting and get that password back, but I have no program to do an outside ioctl call with until later on when the program that can do the call is explicitly run.

    I would like to just immediately running the ramdisk be able to ask the user for a password and then get that password back, but it seems like that is nearly impossible. Any suggestions on how to do that without an outside access application running at the beginning?

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by blahblahblahh View Post
    Hi, I literally have this exact same problem and I was wondering, how would I do this if I don't have an access application? I want to prompt for a password immediately on starting and get that password back, but I have no program to do an outside ioctl call with until later on when the program that can do the call is explicitly run.

    I would like to just immediately running the ramdisk be able to ask the user for a password and then get that password back, but it seems like that is nearly impossible. Any suggestions on how to do that without an outside access application running at the beginning?
    Almost certainly, you can not do that (in a way that is reliable and sensible).

    When in the kernel, you DO NOT communicate with the user [at least not ask the user to enter something]. It is not what the kernel does. This is done by having another application pass in the password. That's how you should do it, and if your teacher has any other ideas, I'd suggest you find another teacher.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Block device I/O under linux, can someone point me in the right direction?
    By BooBoo808 in forum Networking/Device Communication
    Replies: 8
    Last Post: 11-20-2007, 09:08 PM
  2. OpenGL on Linux - Kernel Panic
    By psychopath in forum Game Programming
    Replies: 2
    Last Post: 04-15-2006, 04:07 PM
  3. Compiling Linux kernel on Windows
    By jmd15 in forum Linux Programming
    Replies: 9
    Last Post: 04-10-2006, 07:28 AM
  4. Linux kernel not compiling
    By frenchfry164 in forum Tech Board
    Replies: 2
    Last Post: 04-29-2003, 04:10 PM
  5. linux kernel 2.5
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 07-31-2002, 11:17 PM