On Tue, Jul 5, 2011 at 9:43 AM, Mandeep Sandhu <mandeepsandhu.chd@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
