Re: interview question how does application connects to device
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.
Franlky, I've never used the sysfs interface and mostly know it from 'theoretical' view-point. It was created mostly for providing a uniform way for user-space applications (udev/HAL, driver tools, etc) to interact with a device driver. It exposes the underlying device topology as a directory tree. I'm not sure how sysfs applies to 'filesystem' as it depicts a particular 'device hierarchy tree' within a kernel. As Greg mentioned here, lot filesystem drivers still prefer to use the ioctl interface. However, one use for it which I can see, is for controlling the underlying block device (hard-disk, USB mass storage etc). HTH, -mandeep
2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@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
2011/7/6 Javier Martinez Canillas <martinez.javier@gmail.com>:
2011/7/6 Mandeep Sandhu <mandeepsandhu.chd@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
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
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
participants (3)
-
Greg Freemyer -
Javier Martinez Canillas -
Mandeep Sandhu