interview question how does application connects to device

[Anuz Pratap Singh Tomar]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110717/4e184765/attachment.html