Re: interview question how does application connects to device
On Sun, Jul 17, 2011 at 22:52, Bond jamesbond.2...@gmail.com wrote: Let me know what do you understand from this. And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Sun, Jul 17, 2011 at 4:52 PM, Bond jamesbond.2...@gmail.com wrote: On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Sun, Jul 17, 2011 at 4:40 PM, Bond jamesbond.2...@gmail.com wrote: On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Sun, Jul 17, 2011 at 4:10 PM, Bond jamesbond.2...@gmail.com wrote: On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah pshah.mum...@gmail.com wrote: Hi, On Tue, Jul 5, 2011 at 9:45 AM, Bond jamesbond.2...@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
Re: interview question how does application connects to device
On Sun, Jul 17, 2011 at 9:44 PM, Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Sun, Jul 17, 2011 at 4:52 PM, Bond jamesbond.2...@gmail.com wrote: On Sun, Jul 17, 2011 at 9:17 PM, Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Sun, Jul 17, 2011 at 4:40 PM, Bond jamesbond.2...@gmail.com wrote: On Sun, Jul 17, 2011 at 9:04 PM, Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Sun, Jul 17, 2011 at 4:10 PM, Bond jamesbond.2...@gmail.com wrote: On Tue, Jul 5, 2011 at 11:13 AM, Prashant Shah pshah.mum...@gmail.com wrote: Hi, On Tue, Jul 5, 2011 at 9:45 AM, Bond jamesbond.2...@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
Re: interview question how does application connects to device
On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: On Sun, Jul 17, 2011 at 22:52, Bond jamesbond.2...@gmail.com wrote: Let me know what do you understand from this. And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful. -- Let me know which part of answer answered as how application connects to particular driver.I see answer explaining finer details of device driver mehcanism but I did not see any where answer to original question or if it has been answered I probably have been stupid enough not to be able to follow it. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Sun, Jul 17, 2011 at 1:34 PM, Bond jamesbond.2...@gmail.com wrote: On Sun, Jul 17, 2011 at 9:36 PM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: On Sun, Jul 17, 2011 at 22:52, Bond jamesbond.2...@gmail.com wrote: Let me know what do you understand from this. And Greg already kindly answer that for you too. Didn't you see his answer? And why do you rant here anyway? Simply getting an answer here, you already lucky and you should be thankful. -- Let me know which part of answer answered as how application connects to particular driver.I see answer explaining finer details of device driver mehcanism but I did not see any where answer to original question or if it has been answered I probably have been stupid enough not to be able to follow it. Bond, Here's a trivial userspace example. What is the official userspace method for determining if a harddrive is a traditional rotating disk, or a SSD? I suspect you won't believe it, but it is just: cat /sys/block/sda/queue/rotational. What is the official userspace method for informing the kernel you want to override its determination of rotating and set it to the SSD setting? echo 0 /sys/block/sda/queue/rotational Obviously you can code the userspace app for the above in any language you want. The big thing is that the above is a simple userspace example of userspace interfacing with the kernel via a formal abi. Note I say ABI not API. ioctl changes in different architectures, so while it can make a fine API, it is not a very good ABI. That lack of consistency in its ABI is one of the reasons it is discouraged. sysfs is now the preferred solution for most basic userspace / kernel interaction due to its simplicity and consistent ABI regardless of platform / architecture. You can see how almost trivially easy the userspace side of the interface is. You can also see that it is exactly the same for a 32-bit app and for a 64-bit app. You as a future kernel developer need to know how to write the kernel side of the above. As you do that, you will see that sysfs is designed for passing single parameters back and forth. If you have a need to pass multiple parameters in a single atomic block, the sysfs is not the right choice. netlink sockets would be the most common recommended interface for sending a collection of parameters at one time. ie. ioctl does the same by passing a structure pointer, but as I said before ioctl is now discouraged. Greg ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Mon, Jul 11, 2011 at 1:43 PM, StephanT stman937-linew...@yahoo.com wrote: Hi all, - Original Message - From: Greg Freemyer greg.freem...@gmail.com 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. If ioctl is no longer preferred what is its preferred alternative ? For simple tasks related to processes procfs. (I think procfs is read only from user space) For simple tasks related to devices sysfs (sysfs is read / write from userspace, but uses very simple data formats. No structures as an example. For complex controls, netlink sockets: http://www.linuxjournal.com/article/7356 is a 5 year article I found with a quick grep. Could you, please explain why ioctl felt in disgrace. I really don't recall the details, but I'm almost positive I've seen new patches rejected because they were based on ioctl's. Can someone else please confirm I'm not imagining things. As I recall, it has to do with the various architectures not being easily handled by the ioctl ABI. == Here's one quote I just found from lkml Feb. 2010 Can you describe what your driver is doing? One rule of thumb is that if you already require a character device, using ioctl is the right answer, but you shouldn't create a character device if all you want to do over it is a single ioctl operation. Arnd === Greg ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
My question is, why netlink sockets are better than ioctls? It is not yet another interface to use as a wildcard to pass any data you wan't between the kernel and userpace with the only difference that you use another paradigm? (network sockets with a specific protocol family instead file operations over a device). Sorry if my question is stupid but I just don't get the point. Regards, Javier, I think the main issue with ioctl is that with some architectures, the userspace and kernel compiler treat 64-bit structure members differently, so it is very easy to create a structure which can not easily be passed via a simple pointer in-all-architectures. With netlink sockets, one is expected to have a well defined byte order coming across the socket. Greg Greg, Thank you very much for your answer, I wasn't aware of that ioctl limitation. Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Autònoma de Barcelona Barcelona, Spain ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
2011/7/6 Mandeep Sandhu mandeepsandhu@gmail.com: How would using sysfs be useful if we were to talk about interacting with, let's say, a file system? ioctl's are quite versatile and rather easy to use when one wants to interact with a given FS. For instance, one can manage a Btrfs file system by using an user-level tool, which heavily uses ioctl's. Requiring it to interact with sysfs instead seems like complicating something simple with no apparent purpose. Something that always has caught my attention is why netlink sockets are so popular. I know that ioctl is deprecated and all new kernel code that needs full-duplex communication between userspace and kernelspace shoud use netlink as its interface. But one of the arguments against ioctl is that you don't have type checking which makes really hard to audit the parameters passed from userspace. Also ioctl can be provided by third party as modules (that can also be proprietary binary only ones) which even complicates more to have a general security mechanism. My question is, why netlink sockets are better than ioctls? It is not yet another interface to use as a wildcard to pass any data you wan't between the kernel and userpace with the only difference that you use another paradigm? (network sockets with a specific protocol family instead file operations over a device). Sorry if my question is stupid but I just don't get the point. Regards, -- Javier Martínez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Autònoma de Barcelona Barcelona, Spain ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On 07/05/2011 06:15 AM, Bond wrote: But he was expecting some thing more complex. Well, to be honest, I also was expecting something more complex when I first looked at kernel programming and creating character devices ;) But the file_operations interface is really straight-forward and simple, very nice. Philipp ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals). Thanks, Paraneetharan C On 5 July 2011 12:21, Philipp Ittershagen li...@gate-nine.de wrote: On 07/05/2011 06:15 AM, Bond wrote: But he was expecting some thing more complex. Well, to be honest, I also was expecting something more complex when I first looked at kernel programming and creating character devices ;) But the file_operations interface is really straight-forward and simple, very nice. Philipp ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Paraneetharan C ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran paraneethar...@gmail.com wrote: I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals). I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o. That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device. So when we try to open a device, say /devtyyS0, it's major-minor numbers My info is a little dated, so plz CMIIW. HTH, -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
Oops, accidentally pressed send... On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu mandeepsandhu@gmail.com wrote: On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran paraneethar...@gmail.com wrote: I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals). I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o. That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device. Eg; when we try to open a device, say /dev/ttyS0, it's major-minor numbers (eg: 64-4 on my machine) are used to lookup the file-ops struct and from then on, the VFS passes the read/write calls to this device driver. HTH, -mandeep My info is a little dated, so plz CMIIW. HTH, -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Tue, Jul 5, 2011 at 1:21 PM, Abhijit Pawar apawar.li...@gmail.comwrote: On 5 July 2011 13:01, Mandeep Sandhu mandeepsandhu@gmail.com wrote: Oops, accidentally pressed send... On Tue, Jul 5, 2011 at 12:58 PM, Mandeep Sandhu mandeepsandhu@gmail.com wrote: On Tue, Jul 5, 2011 at 12:29 PM, Paraneetharan Chandrasekaran paraneethar...@gmail.com wrote: I think the thread originator is asking about how the application knows which device file to read or write. This is done by h/w management system udev. udev creates/manages device nodes in /dev/ dir and notifes applications based on the udev rules written (via HAL events or DBUS signals). I don't think udev is involved in the read/write file ops. Udev is responsible for handling hotplug events, doing certain actions based on events (as indicated by udev rules),persistent naming of devices etc...but not file i/o. That, I think, is handled by the VFS layer. Each device node is uniquely identified by it's MAJOR-MINOR number combo. I guess the VFS layer uses this to pick the correct file-ops struct to communicate with the device. Eg; when we try to open a device, say /dev/ttyS0, it's major-minor numbers (eg: 64-4 on my machine) are used to lookup the file-ops struct and from then on, the VFS passes the read/write calls to this device driver. Yes. whenever we read or write to the device, the file operations structure would be invoked for the device. And this device is identified by the Major and Minor number combination. The device driver / kernel module at registration time mention what major and minor it would be servicing. This is what I think it should work. Good to get confirmation though. Udev creates the device node and loads the corresponding driver based on the major/minor no. So after this step udev is out of the picture and control goes on particular device node and then file-operation will come into picture for read and write. It will try to read the data from cache (buffer cache) and if not avilable there then from disk... Regards, Abhijit HTH, -mandeep My info is a little dated, so plz CMIIW. HTH, -mandeep ___ 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Tue, Jul 5, 2011 at 2:43 PM, Mandeep Sandhu mandeepsandhu@gmail.comwrote: picture for read and write. It will try to read the data from cache (buffer cache) and if not avilable there then from disk... This is applicable only for block devices, not for all devices (eg: char dev). Yep...100% true -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Tue, Jul 5, 2011 at 12:15 AM, Bond jamesbond.2...@gmail.com wrote:
This is an interview question.
I had written device driver for a char device so I know that code
structure looks like this
struct file_operations something {
.owner=my_device_open;
.read=my_device_read;
.close=my_device_close;
.write=my_device_write;
}
When the device driver is active then in
/dev/mydevice
you can actually read and write into it. But what I was not clear is
how an application will read or write to this device. I know insmod
will insert the module to kernel,and register_chrdev(); will register
the driver in kernel but how will application program communicate with
this driver.
My answer was
In unix it simply opens the device node as a file and sends/receives
data and commands from it.
But he was expecting some thing more complex.
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.
Greg
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
On Tue, Jul 5, 2011 at 9:15 AM, Bond jamesbond.2...@gmail.com wrote:
This is an interview question.
I had written device driver for a char device so I know that code
structure looks like this
struct file_operations something {
.owner=my_device_open;
.read=my_device_read;
.close=my_device_close;
.write=my_device_write;
}
When the device driver is active then in
/dev/mydevice
you can actually read and write into it. But what I was not clear is
how an application will read or write to this device. I know insmod
will insert the module to kernel,and register_chrdev(); will register
the driver in kernel but how will application program communicate with
this driver.
My answer was
In unix it simply opens the device node as a file and sends/receives
data and commands from it.
But he was expecting some thing more complex.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi,
Not in touch with low level stuff for some time but do check ioctl() and
sysfs on wikipedia or man pages.
Take care.
--
Shahbaz Khan
RD Engineer,
Tactical Engineering and Consultancy.
http://shazkhan.wordpress.com/
http://pk.linkedin.com/pub/shahbaz-khan/20/116/b49
http://imsciences.edu.pk/serg/
http://csrdu.org/
+92-91-332-9915828
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
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. 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? 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? Thanks, -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
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 Greg ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
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
Re: interview question how does application connects to device
Hi, On Wed, Jul 6, 2011 at 9:38 AM, Abhijit Pawar apawar.li...@gmail.com wrote: 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. then what are the alternatives ? are there any articles or documentation for it ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: interview question how does application connects to device
Hi, On Tue, Jul 5, 2011 at 9:45 AM, Bond jamesbond.2...@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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
