interview question how does application connects to device
This is an interview question. I had written device driver for a char device so I know that code structure looks like this struct file_operations something { .owner=my_device_open; .read=my_device_read; .close=my_device_close; .write=my_device_write; } When the device driver is active then in /dev/mydevice you can actually read and write into it. But what I was not clear is how an application will read or write to this device. I know insmod will insert the module to kernel,and register_chrdev(); will register the driver in kernel but how will application program communicate with this driver. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it. But he was expecting some thing more complex.
Hi, On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method : Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected. --
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
Why do not you understand that this has nothing to my selection what I wanted to know is how does the app gets connected to device.And your rant does not help to understand.The answers given on this list are of very poor quality as usual. As an example you rather than answering some thing meaningful reproduced rant.
On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com>
wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
Why do not you understand that this has nothing to my selection what I wanted to know is how does the app gets connected to device.And your rant does not help to understand.The answers given on this list are of very poor quality as usual. As an example you rather than answering some thing meaningful reproduced rant.
Greg Freemyer answered your question with fine details. And the discussion that followed elaborated the point. But you say all that is NOT correct? on what basis did you say that?
On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
Why do not you understand that this has nothing to my selection what I wanted to know is how does the app gets connected to device.And your rant does not help to understand.The answers given on this list are of very poor quality as usual. As an example you rather than answering some thing meaningful reproduced rant.
Greg Freemyer answered your question with fine details. And the discussion that followed elaborated the point. But you say all that is NOT correct? on what basis did you say that?
I am reproducing what he answered And the interviewer was right! You fell short. And so did everyone else in this thread. I'm very surprised at the poor answers this thread generated. Maybe everyone should get a 20+ year old UNIX book an read it so they know the basic and classic mechanisms. My personal favorite old book was "The Magic Garden Explained: The Internals of Unix System V Release 4" To my surprise Amazon has some copies. New and used. It's 20 years old, but it will give some historical pre-linux context. Remember your interviewer is likely to be an old timer, so you need to be familiar with classical UNIX, not just bleeding edge Linux. (Not that the answers showed familiarity with either, but the classic stuff should pop of people's minds without thought.) Back to the question read / write are "data" paths, not control/status/command paths. Yes, there are drivers that abuse read/write to handle commands, but they are the exception, not the rule. In general, read/write are termed in-band communications and using them to communicate with ta driver is discouraged. The Linux kernel encourages out-of-band communications. Let me simplify the question. 1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it). 2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel? 3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000. Personally, anyone that can't answer those basic questions has failed a job interview in my mind. Let me know what do you understand from this. --
On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
Let me know what do you understand from this.
And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
Let me know what do you understand from this.
And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful.
-- Let me know which part of answer answered as how application connects to particular driver.I see answer explaining finer details of device driver mehcanism but I did not see any where answer to original question or if it has been answered I probably have been stupid enough not to be able to follow it.
On Sun, Jul 17, 2011 at 6:34 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
Let me know what do you understand from this.
And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful.
-- Let me know which part of answer answered as how application connects to particular driver.I see answer explaining finer details of device driver mehcanism but I did not see any where answer to original question or if it has been answered I probably have been stupid enough not to be able to follow it.
There have been a lot of discussion on udev and VFS and someone even explained path of data flow from user space to kernel to end device. you need to read more and read carefully. Besides your question is more related to linux application programming and interface. Robert love's other book(Linux system programming) should help you, there is one more book Advanced linux programming, new riders publication. P.S. And I really don't like tone of your mails.
On Sun, Jul 17, 2011 at 1:34 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
On Sun, Jul 17, 2011 at 22:52, Bond <jamesbond.2k.g@gmail.com> wrote:
Let me know what do you understand from this.
And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful.
-- Let me know which part of answer answered as how application connects to particular driver.I see answer explaining finer details of device driver mehcanism but I did not see any where answer to original question or if it has been answered I probably have been stupid enough not to be able to follow it.
Bond, Here's a trivial userspace example. What is the official userspace method for determining if a harddrive is a traditional rotating disk, or a SSD? I suspect you won't believe it, but it is just: cat /sys/block/sda/queue/rotational. What is the official userspace method for informing the kernel you want to override its determination of rotating and set it to the SSD setting? echo 0 > /sys/block/sda/queue/rotational Obviously you can code the userspace app for the above in any language you want. The big thing is that the above is a simple userspace example of userspace interfacing with the kernel via a formal abi. Note I say ABI not API. ioctl changes in different architectures, so while it can make a fine API, it is not a very good ABI. That lack of consistency in its ABI is one of the reasons it is discouraged. sysfs is now the preferred solution for most basic userspace / kernel interaction due to its simplicity and consistent ABI regardless of platform / architecture. You can see how almost trivially easy the userspace side of the interface is. You can also see that it is exactly the same for a 32-bit app and for a 64-bit app. You as a future kernel developer need to know how to write the kernel side of the above. As you do that, you will see that sysfs is designed for passing single parameters back and forth. If you have a need to pass multiple parameters in a single atomic block, the sysfs is not the right choice. netlink sockets would be the most common recommended interface for sending a collection of parameters at one time. ie. ioctl does the same by passing a structure pointer, but as I said before ioctl is now discouraged. Greg
On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com>
wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <
pshah.mumbai@gmail.com>
wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
Why do not you understand that this has nothing to my selection what I wanted to know is how does the app gets connected to device.And your rant does not help to understand.The answers given on this list are of very poor quality as usual. As an example you rather than answering some thing meaningful reproduced rant.
Greg Freemyer answered your question with fine details. And the discussion that followed elaborated the point. But you say all that is NOT correct? on what basis did you say that?
I am reproducing what he answered
And the interviewer was right! You fell short. And so did everyone else in this thread. I'm very surprised at the poor answers this thread generated. Maybe everyone should get a 20+ year old UNIX book an read it so they know the basic and classic mechanisms.
My personal favorite old book was
"The Magic Garden Explained: The Internals of Unix System V Release 4"
To my surprise Amazon has some copies. New and used. It's 20 years old, but it will give some historical pre-linux context. Remember your interviewer is likely to be an old timer, so you need to be familiar with classical UNIX, not just bleeding edge Linux. (Not that the answers showed familiarity with either, but the classic stuff should pop of people's minds without thought.)
Back to the question
read / write are "data" paths, not control/status/command paths. Yes, there are drivers that abuse read/write to handle commands, but they are the exception, not the rule.
In general, read/write are termed in-band communications and using them to communicate with ta driver is discouraged. The Linux kernel encourages out-of-band communications.
Let me simplify the question.
1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it).
2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel?
3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000.
Personally, anyone that can't answer those basic questions has failed a job interview in my mind.
Let me know what do you understand from this.
--
For one he is pointing out that there are more mechanism to interact with devices than just read/write. When you open a device node, you do not have to necessarily read or write. In most cases its not ever required The drivers implement many methods like proc, ioctls, the new sysfs each of which can be directly read from or write to or pass some control/command. For example network drivers don't have device nodes, netlink interface or sockets is used to interact with them. Secondly he is pointing out the fact that some of the interfaces are being deprecated like sysfs will be used for most purpose as compared to proc. In between this discussion, it was also pointed out that seek() call may not be useful for character drivers and its not one of the most important one. another way for interacting with kernel could be using mmap(). I do not exactly remember how it works, but it has been explained here on this list many times.
On Sun, Jul 17, 2011 at 9:44 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@gmail.com> wrote:
On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question. My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
A little more detailed method :
Userland read/write to the file -> Calls C Library read/write functions -> Makes System Calls for read/write -> (now inside kernel) -> Process the system calls (check parameter, etc) -> Refer the file_operations structure for that file -> Call the corresponding read/write function.
This is not correct.If you answer this in interview which I faced as I did not get that job even you will not. The answers on this mailing list did not helped.If you would have been in the interview and given these answers it will not work. Initially I posted the question on list I was expecting I missed some thing or interviewer was blabbering more.But I gave 2-3 more interviews and all of them asked me same and I gave the answers which I learned in this thread but I was not selected.
--
This list is not an interview question answering mailing list. Not getting selected have nothing to do with answers being right or wrong. Being selected in an interview has a lot of other factors.
Why do not you understand that this has nothing to my selection what I wanted to know is how does the app gets connected to device.And your rant does not help to understand.The answers given on this list are of very poor quality as usual. As an example you rather than answering some thing meaningful reproduced rant.
Greg Freemyer answered your question with fine details. And the discussion that followed elaborated the point. But you say all that is NOT correct? on what basis did you say that?
I am reproducing what he answered
And the interviewer was right! You fell short. And so did everyone else in this thread. I'm very surprised at the poor answers this thread generated. Maybe everyone should get a 20+ year old UNIX book an read it so they know the basic and classic mechanisms.
My personal favorite old book was
"The Magic Garden Explained: The Internals of Unix System V Release 4"
To my surprise Amazon has some copies. New and used. It's 20 years old, but it will give some historical pre-linux context. Remember your interviewer is likely to be an old timer, so you need to be familiar with classical UNIX, not just bleeding edge Linux. (Not that the answers showed familiarity with either, but the classic stuff should pop of people's minds without thought.)
Back to the question
read / write are "data" paths, not control/status/command paths. Yes, there are drivers that abuse read/write to handle commands, but they are the exception, not the rule.
In general, read/write are termed in-band communications and using them to communicate with ta driver is discouraged. The Linux kernel encourages out-of-band communications.
Let me simplify the question.
1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it).
2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel?
3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000.
Personally, anyone that can't answer those basic questions has failed a job interview in my mind.
Let me know what do you understand from this.
--
For one he is pointing out that there are more mechanism to interact with devices than just read/write. When you open a device node, you do not have to necessarily read or write. In most cases its not ever required The drivers implement many methods like proc, ioctls, the new sysfs each of which can be directly read from or write to or pass some control/command. For example network drivers don't have device nodes, netlink interface or sockets is used to interact with them. Secondly he is pointing out the fact that some of the interfaces are being deprecated like sysfs will be used for most purpose as compared to proc. In between this discussion, it was also pointed out that seek() call may not be useful for character drivers and its not one of the most important one. another way for interacting with kernel could be using mmap(). I do not exactly remember how it works, but it has been explained here on this list many times.
What I simply want to know is what is the mechanism that application connects to particular device driver and I am not able to understand if this has been answered.I know drivers have methods etc etc but how does application connects to them that is what I want to know.
On 07/05/2011 06:15 AM, Bond wrote:
But he was expecting some thing more complex.
Well, to be honest, I also was expecting something more complex when I first looked at kernel programming and creating character devices ;) But the file_operations interface is really straight-forward and simple, very nice. Philipp
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals). Thanks, Paraneetharan C On 5 July 2011 12:21, Philipp Ittershagen <lists@gate-nine.de> wrote:
On 07/05/2011 06:15 AM, Bond wrote:
But he was expecting some thing more complex.
Well, to be honest, I also was expecting something more complex when I first looked at kernel programming and creating character devices ;) But the file_operations interface is really straight-forward and simple, very nice.
Philipp
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Paraneetharan C
On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran <paraneetharanc@gmail.com> wrote:
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals).
I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o. That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device. So when we try to open a device, say /devtyyS0, it's major-minor numbers My info is a little dated, so plz CMIIW. HTH, -mandeep
Oops, accidentally pressed send... On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran <paraneetharanc@gmail.com> wrote:
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals).
I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o.
That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device.
Eg; when we try to open a device, say /dev/ttyS0, it's major-minor numbers (eg: 64-4 on my machine) are used to lookup the file-ops struct and from then on, the VFS passes the read/write calls to this device driver. HTH, -mandeep
My info is a little dated, so plz CMIIW.
HTH, -mandeep
On 5 July 2011 13:01, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
Oops, accidentally pressed send...
On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran <paraneetharanc@gmail.com> wrote:
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals).
I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o.
That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device.
Eg; when we try to open a device, say /dev/ttyS0, it's major-minor numbers (eg: 64-4 on my machine) are used to lookup the file-ops struct and from then on, the VFS passes the read/write calls to this device driver.
Yes. whenever we read or write to the device, the file operations structure would be invoked for the device. And this device is identified by the Major and Minor number combination. The device driver / kernel module at registration time mention what major and minor it would be servicing. This is what I think it should work. Good to get confirmation though. Regards, Abhijit
HTH, -mandeep
My info is a little dated, so plz CMIIW.
HTH, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Jul 5, 2011 at 1:21 PM, Abhijit Pawar <apawar.linux@gmail.com>wrote:
On 5 July 2011 13:01, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
Oops, accidentally pressed send...
On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran <paraneetharanc@gmail.com> wrote:
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals).
I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o.
That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device.
Eg; when we try to open a device, say /dev/ttyS0, it's major-minor numbers (eg: 64-4 on my machine) are used to lookup the file-ops struct and from then on, the VFS passes the read/write calls to this device driver.
Yes. whenever we read or write to the device, the file operations structure would be invoked for the device. And this device is identified by the Major and Minor number combination. The device driver / kernel module at registration time mention what major and minor it would be servicing.
This is what I think it should work. Good to get confirmation though.
Udev creates the device node and loads the corresponding driver based on the major/minor no. So after this step udev is out of the picture and control goes on particular device node and then file-operation will come into picture for read and write. It will try to read the data from cache (buffer cache) and if not avilable there then from disk...
Regards, Abhijit
HTH, -mandeep
My info is a little dated, so plz CMIIW.
HTH, -mandeep
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Jul 5, 2011 at 2:43 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com>wrote:
picture for read and write. It will try to read the data from cache (buffer cache) and if not avilable there then from disk...
This is applicable only for block devices, not for all devices (eg: char dev).
Yep...100% true....
-mandeep
On Tue, Jul 5, 2011 at 12:15 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question.
I had written device driver for a char device so I know that code structure looks like this
struct file_operations something { .owner=my_device_open; .read=my_device_read; .close=my_device_close; .write=my_device_write;
} When the device driver is active then in
/dev/mydevice you can actually read and write into it. But what I was not clear is how an application will read or write to this device. I know insmod will insert the module to kernel,and register_chrdev(); will register the driver in kernel but how will application program communicate with this driver.
My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
But he was expecting some thing more complex.
And the interviewer was right! You fell short. And so did everyone else in this thread. I'm very surprised at the poor answers this thread generated. Maybe everyone should get a 20+ year old UNIX book an read it so they know the basic and classic mechanisms. My personal favorite old book was "The Magic Garden Explained: The Internals of Unix System V Release 4" To my surprise Amazon has some copies. New and used. It's 20 years old, but it will give some historical pre-linux context. Remember your interviewer is likely to be an old timer, so you need to be familiar with classical UNIX, not just bleeding edge Linux. (Not that the answers showed familiarity with either, but the classic stuff should pop of people's minds without thought.) Back to the question read / write are "data" paths, not control/status/command paths. Yes, there are drivers that abuse read/write to handle commands, but they are the exception, not the rule. In general, read/write are termed in-band communications and using them to communicate with ta driver is discouraged. The Linux kernel encourages out-of-band communications. Let me simplify the question. 1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it). 2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel? 3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000. Personally, anyone that can't answer those basic questions has failed a job interview in my mind. Greg
Let me simplify the question.
I'll attempt to answer your questions...for my own edification! :)
1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it).
open/close/read/write/seek?...and the infamous ioctl.
2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel?
I'm guessing this is ioctl's...because now the preferred way to communicate/give commands to a device is via sysfs?
3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000.
ioctl's, profs/sysfs, netlink sockets maybe? Thanks, -mandeep
On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
Let me simplify the question.
I'll attempt to answer your questions...for my own edification! :)
1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it).
open/close/read/write/seek?...and the infamous ioctl.
You listed 6. Historically character devices don't seek. So drop that one to get to 5. (And yes, you can find char devices that implement seek, but ioctl is far more common. And when I learned UNIX 30 years ago, it was just the basic 5 I'm pretty sure that actually have matching driver code..) That is, drivers don't implement seek. seek() just sets a offset variable tracked in the kernel. The driver is not even woken up when the happens. That is if userspace did: open() seek(1) seek(2) seek(3) write() The driver would get invoked for open, and again for write. When write is invoked, the offset field would have a 3 in it. The driver has no way to even know seek(1) and seek(2) calls were made. So if you read a kernel book, you'll find seek() gets very little attention. It's really just a glorified way to say offset=value;
2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel?
I'm guessing this is ioctl's...because now the preferred way to communicate/give commands to a device is via sysfs?
Correct, ioctl is no longer preferred, but it is definitely still used. And the ext4 team is still adding new ioctl commands despite it being discouraged. (I don't know why they are able to do that, but I know they do.)
3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000.
ioctl's, profs/sysfs, netlink sockets maybe?
Yes, except procfs and sysfs are 2 different solutions, so you named 4. As of 2011, both ioctl's and procfs are discouraged for new "device driver" use. ioctl's will likely be around forever just because there are so many legacy ioctl implementations that need to be supported. Think of stty. That is a hugely complex ioctl based tool that I seriously doubt ever gets rewritten with a new kernel interface. procfs on they other hand will hopefully lose all the non-process specific users, but keep the process specific ones. That is, the current preference is /proc should only have info related to running processes, not all the other miscellaneous stuff. I don’t think there is yet an effort to remove those other files, but hopefully there will be gone at some point. One thing to keep in mind is that anything that interfaces with userspace is part of the kernel ABI and becomes very hard to change / get rid of. That actually means that any patches / driver submissions that impact on the kernel / userspace interface get a extra hard look. It also means a perspective employer will want to make sure you really understand the userspace / kernel interface. It is just too hard to throw out a implementation once accepted by LKML. Even in a embedded world where the driver is not sent upstream you want the kernel ABI to be as stable as possible. Otherwise you have to always be ensuring your kernel and userspace apps are compatible versions.
Thanks, -mandeep
Hope that helps at least someone in a future interview Greg
On 5 July 2011 21:33, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com> wrote:
Let me simplify the question.
I'll attempt to answer your questions...for my own edification! :)
1) What are the FIVE classic system calls for interfacing with a character device. (ie. If it did not exist in 1970, don't list it).
open/close/read/write/seek?...and the infamous ioctl.
You listed 6. Historically character devices don't seek. So drop that one to get to 5.
(And yes, you can find char devices that implement seek, but ioctl is far more common. And when I learned UNIX 30 years ago, it was just the basic 5 I'm pretty sure that actually have matching driver code..)
That is, drivers don't implement seek. seek() just sets a offset variable tracked in the kernel. The driver is not even woken up when the happens.
That is if userspace did:
open() seek(1) seek(2) seek(3) write()
The driver would get invoked for open, and again for write. When write is invoked, the offset field would have a 3 in it. The driver has no way to even know seek(1) and seek(2) calls were made.
So if you read a kernel book, you'll find seek() gets very little attention. It's really just a glorified way to say offset=value;
2) Which of the 5 is still heavily used in the kernel but is discouraged for new drivers being accepted into the linux kernel?
I'm guessing this is ioctl's...because now the preferred way to communicate/give commands to a device is via sysfs?
Correct, ioctl is no longer preferred, but it is definitely still used. And the ext4 team is still adding new ioctl commands despite it being discouraged.
(I don't know why they are able to do that, but I know they do.)
3) Name at least 3 alternatives that have been routinely used for out-of-band communication in the Linux kernel since 2000.
ioctl's, profs/sysfs, netlink sockets maybe?
Yes, except procfs and sysfs are 2 different solutions, so you named 4.
As of 2011, both ioctl's and procfs are discouraged for new "device driver" use.
ioctl's will likely be around forever just because there are so many legacy ioctl implementations that need to be supported. Think of stty. That is a hugely complex ioctl based tool that I seriously doubt ever gets rewritten with a new kernel interface.
procfs on they other hand will hopefully lose all the non-process specific users, but keep the process specific ones. That is, the current preference is /proc should only have info related to running processes, not all the other miscellaneous stuff. I don’t think there is yet an effort to remove those other files, but hopefully there will be gone at some point.
One thing to keep in mind is that anything that interfaces with userspace is part of the kernel ABI and becomes very hard to change / get rid of.
That actually means that any patches / driver submissions that impact on the kernel / userspace interface get a extra hard look.
It also means a perspective employer will want to make sure you really understand the userspace / kernel interface. It is just too hard to throw out a implementation once accepted by LKML. Even in a embedded world where the driver is not sent upstream you want the kernel ABI to be as stable as possible. Otherwise you have to always be ensuring your kernel and userspace apps are compatible versions.
Thanks, -mandeep
Hope that helps at least someone in a future interview
This is good. One more addition from my side which is not necessarily the answer to Greg's question: Bottom Halves are discouraged now days in driver.
Greg
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi, On Wed, Jul 6, 2011 at 9:38 AM, Abhijit Pawar <apawar.linux@gmail.com> wrote:
This is good. One more addition from my side which is not necessarily the answer to Greg's question: Bottom Halves are discouraged now days in driver.
then what are the alternatives ? are there any articles or documentation for it ?
On 6 July 2011 10:13, Prashant Shah <pshah.mumbai@gmail.com> wrote:
Hi,
On Wed, Jul 6, 2011 at 9:38 AM, Abhijit Pawar <apawar.linux@gmail.com> wrote:
This is good. One more addition from my side which is not necessarily the answer to Greg's question: Bottom Halves are discouraged now days in
driver.
then what are the alternatives ? are there any articles or documentation for it ?
Tasklets or workqueues. Please refer to LDD3 chapter 10. I should have written that older bottom halves are not supported. my mistake. Regards, Abhijit
Hi all, ----- Original Message -----
From: Greg Freemyer <greg.freemyer@gmail.com>
Correct, ioctl is no longer preferred, but it is definitely still used. And the ext4 team is still adding new ioctl commands despite it being discouraged.
If ioctl is no longer preferred what is its preferred alternative ? Could you, please explain why ioctl felt in disgrace. Thanks, Stephan.
On Mon, Jul 11, 2011 at 10:43:50AM -0700, StephanT wrote:
Hi all,
----- Original Message -----
From: Greg Freemyer <greg.freemyer@gmail.com>
Correct, ioctl is no longer preferred, but it is definitely still used. And the ext4 team is still adding new ioctl commands despite it being discouraged.
If ioctl is no longer preferred what is its preferred alternative ?
a virtual filesystem, sysfs, debugfs, configfs, or something else is usually all you need. As mentioned, netlink is also a good alternative, and so is the connector interface.
Could you, please explain why ioctl felt in disgrace.
It's essencially adding a brand new system call every single time, 32/64bit problems, pointer problems, structure problems, incorrect bounds checking almost always happens and other nastyness. That being said, there are still times when ioctl is the correct thing to use, but you have to really know what you are doing and be able to justify it. hope this helps, greg k-h
On Mon, Jul 11, 2011 at 1:43 PM, StephanT <stman937-linewbie@yahoo.com> wrote:
Hi all,
----- Original Message -----
From: Greg Freemyer <greg.freemyer@gmail.com>
Correct, ioctl is no longer preferred, but it is definitely still used. And the ext4 team is still adding new ioctl commands despite it being discouraged.
If ioctl is no longer preferred what is its preferred alternative ?
For simple tasks related to processes procfs. (I think procfs is read only from user space) For simple tasks related to devices sysfs (sysfs is read / write from userspace, but uses very simple data formats. No structures as an example. For complex controls, netlink sockets: http://www.linuxjournal.com/article/7356 is a 5 year article I found with a quick grep.
Could you, please explain why ioctl felt in disgrace.
I really don't recall the details, but I'm almost positive I've seen new patches rejected because they were based on ioctl's. Can someone else please confirm I'm not imagining things. As I recall, it has to do with the various architectures not being easily handled by the ioctl ABI. ==> Here's one quote I just found from lkml Feb. 2010 Can you describe what your driver is doing? One rule of thumb is that if you already require a character device, using ioctl is the right answer, but you shouldn't create a character device if all you want to do over it is a single ioctl operation. Arnd === Greg
On Tue, Jul 5, 2011 at 9:15 AM, Bond <jamesbond.2k.g@gmail.com> wrote:
This is an interview question.
I had written device driver for a char device so I know that code structure looks like this
struct file_operations something { .owner=my_device_open; .read=my_device_read; .close=my_device_close; .write=my_device_write;
} When the device driver is active then in
/dev/mydevice you can actually read and write into it. But what I was not clear is how an application will read or write to this device. I know insmod will insert the module to kernel,and register_chrdev(); will register the driver in kernel but how will application program communicate with this driver.
My answer was In unix it simply opens the device node as a file and sends/receives data and commands from it.
But he was expecting some thing more complex.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi, Not in touch with low level stuff for some time but do check ioctl() and sysfs on wikipedia or man pages. Take care. -- Shahbaz Khan R&D Engineer, Tactical Engineering and Consultancy. http://shazkhan.wordpress.com/ http://pk.linkedin.com/pub/shahbaz-khan/20/116/b49 http://imsciences.edu.pk/serg/ http://csrdu.org/ +92-91-332-9915828
participants (13)
-
Abhijit Pawar -
Anuz Pratap Singh Tomar -
Bond -
er krishna -
Greg Freemyer -
Greg KH -
Mandeep Sandhu -
Mulyadi Santosa -
Paraneetharan Chandrasekaran -
Philipp Ittershagen -
Prashant Shah -
Shaz -
StephanT