开发者

Replacement for the ioctl() function

开发者 https://www.devze.com 2023-04-02 21:18 出处:网络
I am developing a device driver I/O model for small microcontroller applications, using POSIX as a guideline for interface design. I implemented ioctl() as a means of controlling d开发者_如何转开发riv

I am developing a device driver I/O model for small microcontroller applications, using POSIX as a guideline for interface design. I implemented ioctl() as a means of controlling d开发者_如何转开发river/hardware parameters – for example UART baud rate, I2C slave address, etc.

I notice, that POSIX:2008 lists ioctl() and <stropts.h> as obsolescent. What is the recommended alternative mechanism for communicating with a device driver?


POSIX only defines a very limited subset of ioctl() functionality - that related to STREAMS. Since the STREAMS facility is obsolescent, the interface to it is also obsolescent in POSIX.

However, ioctl() has been part of Unix since 'forever' (it was certainly in 7th Edition UNIX, and I am tolerably certain it was not new even then). It is 'the way' to control device drivers after they are open. The only issue is that such interfaces and controls are not standardized.

You could take a look at the <termios.h> files for a set of functions written to control terminals. I expect that the typical implementation uses ioctl() or other similar specialized mechanisms, but the interface was made general when it was standardized (the <termios.h> interface is not identical to any earlier interface, either the 7th Edition or the System III or any other interface). If you wanted to, you could write standard functions atop your ioctl() interface that your users would use; you would implement those functions to call onto your ioctl() interface.

So, ioctl() isn't going away; it is the correct way to control device drivers. POSIX has a slightly different agenda, that's all.

0

精彩评论

暂无评论...
验证码 换一张
取 消