On 5 July 2011 21:33, Greg Freemyer <greg.freem...@gmail.com> wrote: > On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu > <mandeepsandhu....@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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
