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

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

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.

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

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

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 */
}

---

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.

Quote:

---

Originally Posted by inferno_gogo

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

Originally Posted by root4

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

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?

Quote:

---

Originally Posted by blahblahblahh

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