interview question how does application connects to device

[Greg Freemyer]

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
Greg