On 08:19 Tue 12 Feb 2008, Robert P. J. Day wrote: > On Mon, 11 Feb 2008, Mayank Kaushik wrote: > > On Feb 8, 2008 2:28 AM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > > see? total freedom in terms of how you interpret the values, which is > > > why ioctl() calls are actually deprecated these days -- they're just > > > too unstructured, and are being phased out in terms of /proc or sysfs > > > entries. but there's obviously a lot of them still in the kernel. > > > > > > > They are being phased out? You mean they may not be supported in future > > kernel versions? > > And is the alternative to ioctl()s, reading/writing to special /proc or > > /sysfs entries? Is that faster/slower than ioctl()s, or just cleaner. > > just FYI, i may have phrased it overly strongly that ioctl's were on > their way out -- there's obviously a lot of them still in the kernel, > but just as obviously, they're considered old school, as you can read > here in this article from way back in 2001. > > http://lwn.net/2001/0524/kernel.php3 > > i doubt they'll ever *truly* go away, but there are obviously better > alternatives these days with /proc and /sys. First, never use /proc for new APIs. It is designed for inspecting processes not displaying Kernel information. Any other use is considered bad form now a days. Secondly, sysfs will never deprecate ioctls. For one really important reason: sysfs is one value per file so you can't read or write a multi-value structures atomically. This is a problem in a very large number of cases such as: userspace USB drivers using control endpoints, frame information in video4linux and countless others. ioctls won't be deprecated and sysfs is not a better alternative in a lot of cases. Cheers, Brandon -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
