* interview question how does application connects to device [not found] <CAOQuo6Nf9-uXBbHOi1_tpBmBOVPzuBtW699=ywDGSsfT_NVphA@mail.gmail.com> @ 2011-07-05 4:15 ` Bond 2011-07-05 5:43 ` Prashant Shah ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: Bond @ 2011-07-05 4:15 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 4:15 ` interview question how does application connects to device Bond @ 2011-07-05 5:43 ` Prashant Shah 2011-07-17 15:10 ` Bond 2011-07-05 6:51 ` Philipp Ittershagen ` (2 subsequent siblings) 3 siblings, 1 reply; 35+ messages in thread From: Prashant Shah @ 2011-07-05 5:43 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 5:43 ` Prashant Shah @ 2011-07-17 15:10 ` Bond 2011-07-17 15:34 ` Anuz Pratap Singh Tomar 0 siblings, 1 reply; 35+ messages in thread From: Bond @ 2011-07-17 15:10 UTC (permalink / raw) To: kernelnewbies 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. -- ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:10 ` Bond @ 2011-07-17 15:34 ` Anuz Pratap Singh Tomar 2011-07-17 15:40 ` Bond 0 siblings, 1 reply; 35+ messages in thread From: Anuz Pratap Singh Tomar @ 2011-07-17 15:34 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/3b78a686/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:34 ` Anuz Pratap Singh Tomar @ 2011-07-17 15:40 ` Bond 2011-07-17 15:47 ` Anuz Pratap Singh Tomar 0 siblings, 1 reply; 35+ messages in thread From: Bond @ 2011-07-17 15:40 UTC (permalink / raw) To: 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:40 ` Bond @ 2011-07-17 15:47 ` Anuz Pratap Singh Tomar 2011-07-17 15:52 ` Bond 0 siblings, 1 reply; 35+ messages in thread From: Anuz Pratap Singh Tomar @ 2011-07-17 15:47 UTC (permalink / raw) To: kernelnewbies 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/9fd3cf40/attachment-0001.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:47 ` Anuz Pratap Singh Tomar @ 2011-07-17 15:52 ` Bond 2011-07-17 16:06 ` Mulyadi Santosa 2011-07-17 16:14 ` Anuz Pratap Singh Tomar 0 siblings, 2 replies; 35+ messages in thread From: Bond @ 2011-07-17 15:52 UTC (permalink / raw) To: kernelnewbies 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. -- ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:52 ` Bond @ 2011-07-17 16:06 ` Mulyadi Santosa 2011-07-17 17:34 ` Bond 2011-07-17 16:14 ` Anuz Pratap Singh Tomar 1 sibling, 1 reply; 35+ messages in thread From: Mulyadi Santosa @ 2011-07-17 16:06 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 16:06 ` Mulyadi Santosa @ 2011-07-17 17:34 ` Bond 2011-07-17 17:49 ` Anuz Pratap Singh Tomar 2011-07-17 19:25 ` Greg Freemyer 0 siblings, 2 replies; 35+ messages in thread From: Bond @ 2011-07-17 17:34 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 17:34 ` Bond @ 2011-07-17 17:49 ` Anuz Pratap Singh Tomar 2011-07-17 19:25 ` Greg Freemyer 1 sibling, 0 replies; 35+ messages in thread From: Anuz Pratap Singh Tomar @ 2011-07-17 17:49 UTC (permalink / raw) To: kernelnewbies 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/e2694d25/attachment-0001.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 17:34 ` Bond 2011-07-17 17:49 ` Anuz Pratap Singh Tomar @ 2011-07-17 19:25 ` Greg Freemyer 1 sibling, 0 replies; 35+ messages in thread From: Greg Freemyer @ 2011-07-17 19:25 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 15:52 ` Bond 2011-07-17 16:06 ` Mulyadi Santosa @ 2011-07-17 16:14 ` Anuz Pratap Singh Tomar 2011-07-17 17:31 ` Bond 1 sibling, 1 reply; 35+ messages in thread From: Anuz Pratap Singh Tomar @ 2011-07-17 16:14 UTC (permalink / raw) To: kernelnewbies 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/4e184765/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-17 16:14 ` Anuz Pratap Singh Tomar @ 2011-07-17 17:31 ` Bond 0 siblings, 0 replies; 35+ messages in thread From: Bond @ 2011-07-17 17:31 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 4:15 ` interview question how does application connects to device Bond 2011-07-05 5:43 ` Prashant Shah @ 2011-07-05 6:51 ` Philipp Ittershagen 2011-07-05 6:59 ` Paraneetharan Chandrasekaran 2011-07-05 12:56 ` Greg Freemyer 2011-07-05 13:36 ` Shaz 3 siblings, 1 reply; 35+ messages in thread From: Philipp Ittershagen @ 2011-07-05 6:51 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 6:51 ` Philipp Ittershagen @ 2011-07-05 6:59 ` Paraneetharan Chandrasekaran 2011-07-05 7:28 ` Mandeep Sandhu 0 siblings, 1 reply; 35+ messages in thread From: Paraneetharan Chandrasekaran @ 2011-07-05 6:59 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Paraneetharan C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/cba31b88/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 6:59 ` Paraneetharan Chandrasekaran @ 2011-07-05 7:28 ` Mandeep Sandhu 2011-07-05 7:31 ` Mandeep Sandhu 0 siblings, 1 reply; 35+ messages in thread From: Mandeep Sandhu @ 2011-07-05 7:28 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 7:28 ` Mandeep Sandhu @ 2011-07-05 7:31 ` Mandeep Sandhu 2011-07-05 7:51 ` Abhijit Pawar 0 siblings, 1 reply; 35+ messages in thread From: Mandeep Sandhu @ 2011-07-05 7:31 UTC (permalink / raw) To: kernelnewbies 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 > ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 7:31 ` Mandeep Sandhu @ 2011-07-05 7:51 ` Abhijit Pawar 2011-07-05 8:12 ` er krishna 0 siblings, 1 reply; 35+ messages in thread From: Abhijit Pawar @ 2011-07-05 7:51 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/d6d31f80/attachment-0001.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 7:51 ` Abhijit Pawar @ 2011-07-05 8:12 ` er krishna 2011-07-05 9:13 ` Mandeep Sandhu 0 siblings, 1 reply; 35+ messages in thread From: er krishna @ 2011-07-05 8:12 UTC (permalink / raw) To: 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 at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/3c26c3a7/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 8:12 ` er krishna @ 2011-07-05 9:13 ` Mandeep Sandhu 2011-07-05 9:38 ` er krishna 0 siblings, 1 reply; 35+ messages in thread From: Mandeep Sandhu @ 2011-07-05 9:13 UTC (permalink / raw) To: kernelnewbies > 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). -mandeep ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 9:13 ` Mandeep Sandhu @ 2011-07-05 9:38 ` er krishna 0 siblings, 0 replies; 35+ messages in thread From: er krishna @ 2011-07-05 9:38 UTC (permalink / raw) To: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/7766b422/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 4:15 ` interview question how does application connects to device Bond 2011-07-05 5:43 ` Prashant Shah 2011-07-05 6:51 ` Philipp Ittershagen @ 2011-07-05 12:56 ` Greg Freemyer 2011-07-05 13:43 ` Mandeep Sandhu 2011-07-05 13:36 ` Shaz 3 siblings, 1 reply; 35+ messages in thread From: Greg Freemyer @ 2011-07-05 12:56 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 12:56 ` Greg Freemyer @ 2011-07-05 13:43 ` Mandeep Sandhu 2011-07-05 16:03 ` Greg Freemyer [not found] ` <769A0B32-0869-4A2B-A005-D6AC0376D1E3@gmail.com> 0 siblings, 2 replies; 35+ messages in thread From: Mandeep Sandhu @ 2011-07-05 13:43 UTC (permalink / raw) To: kernelnewbies > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 13:43 ` Mandeep Sandhu @ 2011-07-05 16:03 ` Greg Freemyer 2011-07-06 4:08 ` Abhijit Pawar 2011-07-11 17:43 ` StephanT [not found] ` <769A0B32-0869-4A2B-A005-D6AC0376D1E3@gmail.com> 1 sibling, 2 replies; 35+ messages in thread From: Greg Freemyer @ 2011-07-05 16:03 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 16:03 ` Greg Freemyer @ 2011-07-06 4:08 ` Abhijit Pawar 2011-07-06 4:43 ` Prashant Shah 2011-07-11 17:43 ` StephanT 1 sibling, 1 reply; 35+ messages in thread From: Abhijit Pawar @ 2011-07-06 4:08 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110706/11d4b948/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-06 4:08 ` Abhijit Pawar @ 2011-07-06 4:43 ` Prashant Shah 2011-07-06 5:27 ` Abhijit Pawar 0 siblings, 1 reply; 35+ messages in thread From: Prashant Shah @ 2011-07-06 4:43 UTC (permalink / raw) To: 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 ? ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-06 4:43 ` Prashant Shah @ 2011-07-06 5:27 ` Abhijit Pawar 0 siblings, 0 replies; 35+ messages in thread From: Abhijit Pawar @ 2011-07-06 5:27 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110706/3b9d7080/attachment-0001.html ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 16:03 ` Greg Freemyer 2011-07-06 4:08 ` Abhijit Pawar @ 2011-07-11 17:43 ` StephanT 2011-07-11 18:13 ` Greg KH 2011-07-11 18:14 ` Greg Freemyer 1 sibling, 2 replies; 35+ messages in thread From: StephanT @ 2011-07-11 17:43 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-11 17:43 ` StephanT @ 2011-07-11 18:13 ` Greg KH 2011-07-11 18:14 ` Greg Freemyer 1 sibling, 0 replies; 35+ messages in thread From: Greg KH @ 2011-07-11 18:13 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-11 17:43 ` StephanT 2011-07-11 18:13 ` Greg KH @ 2011-07-11 18:14 ` Greg Freemyer 1 sibling, 0 replies; 35+ messages in thread From: Greg Freemyer @ 2011-07-11 18:14 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <769A0B32-0869-4A2B-A005-D6AC0376D1E3@gmail.com>]
* interview question how does application connects to device [not found] ` <769A0B32-0869-4A2B-A005-D6AC0376D1E3@gmail.com> @ 2011-07-06 5:12 ` Mandeep Sandhu 2011-07-06 23:29 ` Javier Martinez Canillas 0 siblings, 1 reply; 35+ messages in thread From: Mandeep Sandhu @ 2011-07-06 5:12 UTC (permalink / raw) To: kernelnewbies > How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS. > > For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose. Franlky, I've never used the sysfs interface and mostly know it from 'theoretical' view-point. It was created mostly for providing a uniform way for user-space applications (udev/HAL, driver tools, etc) to interact with a device driver. It exposes the underlying device topology as a directory tree. I'm not sure how sysfs applies to 'filesystem' as it depicts a particular 'device hierarchy tree' within a kernel. As Greg mentioned here, lot filesystem drivers still prefer to use the ioctl interface. However, one use for it which I can see, is for controlling the underlying block device (hard-disk, USB mass storage etc). HTH, -mandeep ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-06 5:12 ` Mandeep Sandhu @ 2011-07-06 23:29 ` Javier Martinez Canillas 2011-07-07 3:20 ` Greg Freemyer 0 siblings, 1 reply; 35+ messages in thread From: Javier Martinez Canillas @ 2011-07-06 23:29 UTC (permalink / raw) To: kernelnewbies 2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@gmail.com>: >> How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS. >> >> For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose. > Something that always has caught my attention is why netlink sockets are so popular. I know that ioctl is deprecated and all new kernel code that needs full-duplex communication between userspace and kernelspace shoud use netlink as its interface. But one of the arguments against ioctl is that you don't have type checking which makes really hard to audit the parameters passed from userspace. Also ioctl can be provided by third party as modules (that can also be proprietary binary only ones) which even complicates more to have a general security mechanism. My question is, why netlink sockets are better than ioctls? It is not yet another interface to use as a wildcard to pass any data you wan't between the kernel and userpace with the only difference that you use another paradigm? (network sockets with a specific protocol family instead file operations over a device). Sorry if my question is stupid but I just don't get the point. Regards, -- Javier Mart?nez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Aut?noma de Barcelona Barcelona, Spain ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-06 23:29 ` Javier Martinez Canillas @ 2011-07-07 3:20 ` Greg Freemyer 2011-07-07 12:51 ` Javier Martinez Canillas 0 siblings, 1 reply; 35+ messages in thread From: Greg Freemyer @ 2011-07-07 3:20 UTC (permalink / raw) To: kernelnewbies 2011/7/6 Javier Martinez Canillas <martinez.javier@gmail.com>: > 2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@gmail.com>: >>> How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS. >>> >>> For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose. >> > > Something that always has caught my attention is why netlink sockets > are so popular. I know that ioctl is deprecated and all new kernel > code that needs full-duplex communication between userspace and > kernelspace shoud use netlink as its interface. > > But one of the arguments against ioctl is that you don't have type > checking which makes really hard to audit the parameters passed from > userspace. Also ioctl can be provided by third party as modules (that > can also be proprietary binary only ones) which even complicates more > to have a general security mechanism. > > My question is, why netlink sockets are better than ioctls? It is not > yet another interface to use as a wildcard to pass any data you wan't > between the kernel and userpace with the only difference that you use > another paradigm? (network sockets with a specific protocol family > instead file operations over a device). > > Sorry if my question is stupid but I just don't get the point. > > Regards, > > -- > Javier Mart?nez Canillas > (+34) 682 39 81 69 > PhD Student in High Performance Computing > Computer Architecture and Operating System Department (CAOS) > Universitat Aut?noma de Barcelona > Barcelona, Spain > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Javier, I think the main issue with ioctl is that with some architectures, the userspace and kernel compiler treat 64-bit structure members differently, so it is very easy to create a structure which can not easily be passed via a simple pointer in-all-architectures. With netlink sockets, one is expected to have a well defined byte order coming across the socket. Greg ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-07 3:20 ` Greg Freemyer @ 2011-07-07 12:51 ` Javier Martinez Canillas 0 siblings, 0 replies; 35+ messages in thread From: Javier Martinez Canillas @ 2011-07-07 12:51 UTC (permalink / raw) To: kernelnewbies >> My question is, why netlink sockets are better than ioctls? It is not >> yet another interface to use as a wildcard to pass any data you wan't >> between the kernel and userpace with the only difference that you use >> another paradigm? (network sockets with a specific protocol family >> instead file operations over a device). >> >> Sorry if my question is stupid but I just don't get the point. >> >> Regards, >> > Javier, > > I think the main issue with ioctl is that with some architectures, the > userspace and kernel compiler treat 64-bit structure members > differently, so it is very easy to create a structure which can not > easily be passed via a simple pointer in-all-architectures. > > With netlink sockets, one is expected to have a well defined byte > order coming across the socket. > > Greg > Greg, Thank you very much for your answer, I wasn't aware of that ioctl limitation. Best regards, -- Javier Mart?nez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Aut?noma de Barcelona Barcelona, Spain ^ permalink raw reply [flat|nested] 35+ messages in thread
* interview question how does application connects to device 2011-07-05 4:15 ` interview question how does application connects to device Bond ` (2 preceding siblings ...) 2011-07-05 12:56 ` Greg Freemyer @ 2011-07-05 13:36 ` Shaz 3 siblings, 0 replies; 35+ messages in thread From: Shaz @ 2011-07-05 13:36 UTC (permalink / raw) To: kernelnewbies 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110705/66a69140/attachment.html ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2011-07-17 19:25 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAOQuo6Nf9-uXBbHOi1_tpBmBOVPzuBtW699=ywDGSsfT_NVphA@mail.gmail.com> 2011-07-05 4:15 ` interview question how does application connects to device Bond 2011-07-05 5:43 ` Prashant Shah 2011-07-17 15:10 ` Bond 2011-07-17 15:34 ` Anuz Pratap Singh Tomar 2011-07-17 15:40 ` Bond 2011-07-17 15:47 ` Anuz Pratap Singh Tomar 2011-07-17 15:52 ` Bond 2011-07-17 16:06 ` Mulyadi Santosa 2011-07-17 17:34 ` Bond 2011-07-17 17:49 ` Anuz Pratap Singh Tomar 2011-07-17 19:25 ` Greg Freemyer 2011-07-17 16:14 ` Anuz Pratap Singh Tomar 2011-07-17 17:31 ` Bond 2011-07-05 6:51 ` Philipp Ittershagen 2011-07-05 6:59 ` Paraneetharan Chandrasekaran 2011-07-05 7:28 ` Mandeep Sandhu 2011-07-05 7:31 ` Mandeep Sandhu 2011-07-05 7:51 ` Abhijit Pawar 2011-07-05 8:12 ` er krishna 2011-07-05 9:13 ` Mandeep Sandhu 2011-07-05 9:38 ` er krishna 2011-07-05 12:56 ` Greg Freemyer 2011-07-05 13:43 ` Mandeep Sandhu 2011-07-05 16:03 ` Greg Freemyer 2011-07-06 4:08 ` Abhijit Pawar 2011-07-06 4:43 ` Prashant Shah 2011-07-06 5:27 ` Abhijit Pawar 2011-07-11 17:43 ` StephanT 2011-07-11 18:13 ` Greg KH 2011-07-11 18:14 ` Greg Freemyer [not found] ` <769A0B32-0869-4A2B-A005-D6AC0376D1E3@gmail.com> 2011-07-06 5:12 ` Mandeep Sandhu 2011-07-06 23:29 ` Javier Martinez Canillas 2011-07-07 3:20 ` Greg Freemyer 2011-07-07 12:51 ` Javier Martinez Canillas 2011-07-05 13:36 ` Shaz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.