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.