On Sun, Jul 17, 2011 at 9:44 PM, Anuz Pratap Singh Tomar <chambilkethakur@xxxxxxxxx> wrote: > > > On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g@xxxxxxxxx> wrote: >> >> On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar >> <chambilkethakur@xxxxxxxxx> wrote: >> > >> > >> > On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g@xxxxxxxxx> wrote: >> >> >> >> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar >> >> <chambilkethakur@xxxxxxxxx> wrote: >> >> > >> >> > >> >> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g@xxxxxxxxx> >> >> > wrote: >> >> >> >> >> >> On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah >> >> >> <pshah.mumbai@xxxxxxxxx> >> >> >> wrote: >> >> >> > Hi, >> >> >> > >> >> >> > On Tue, Jul 5, 2011 at 9:45 AM, Bond <jamesbond.2k.g@xxxxxxxxx> >> >> >> > 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
