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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
