interview question how does application connects to device

[Abhijit Pawar]

On 5 July 2011 21:33, Greg Freemyer <greg.freemyer at gmail.com> wrote:

> On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu
> <mandeepsandhu.chd at 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