interview question how does application connects to device

[Bond]

On Sun, Jul 17, 2011 at 9:44 PM, Anuz Pratap Singh Tomar
<chambilkethakur at gmail.com> wrote:
>
>
> On Sun, Jul 17, 2011 at 4:52 PM, Bond <jamesbond.2k.g at gmail.com> wrote:
>>
>> On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar
>> <chambilkethakur at gmail.com> wrote:
>> >
>> >
>> > On Sun, Jul 17, 2011 at 4:40 PM, Bond <jamesbond.2k.g at gmail.com> wrote:
>> >>
>> >> On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar
>> >> <chambilkethakur at gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Sun, Jul 17, 2011 at 4:10 PM, Bond <jamesbond.2k.g at 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 at 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.