ioctl

[Love4Boobies]

Two important things that I haven't seen mentioned here:

• ioctl is actually only defined for STREAMS. It's much less general than people usually think.
• The STREAMS interface is being deprecated.

[Combuster]

Not in those words, but still:

Since all the official posix things ioctl was meant to do is pretty much useless, any meaningful use of ioctl you will be seeing in practice is just nonportable code talking to (linux-)specific interfaces

[Brynet-Inc]

Regardless of inevitable deprecation by standards bodies, ioctl() won't be disappearing any time soon.

The DRM (Direct Rendering Manager) interface is one API using ioctl that is widely implemented on both BSD, Linux and other Unix systems.. IMHO, it is more portable then some other monstrosities, such as "/sys or /proc".

On BSD, several drivers or "pseudo-devices" expose an ioctl() interface, it is handy for potentially unportable things like power management, network configuration, manipulating ttys (init/getty/shells/terminal emulators).. or even controlling ones tape drives.

Userland programs can use preprocessor directives and/or return values/errno for dealing with OS-specific backends, but for system utilities that are inherently unportable, it may not even matter.

[Brynet-Inc]

Two important things that I haven't seen mentioned here:

• ioctl is actually only defined for STREAMS. It's much less general than people usually think.
• The STREAMS interface is being deprecated.

V7 Unix introduced ioctl() as a general device control interface, and it was adopted by BSD developers (..in reality, everybody) for that purpose.

The STREAMS ioctl specified in POSIX was optional and implemented by precisely nobody.

[Love4Boobies]

Well, that is a bit of an exaggeration but STREAMS was indeed never popular (because of BSD sockets, etc.), which is why it is obsolescent, even if it is interesting. The point I was trying to make is the same one Combuster had made in a previous post (that I originally missed): Many people use the same name, ioctl, for many different routines. Talking about the portability of a non-POSIX ioctl makes as much sense as talking about the portability of kmain.

[Brynet-Inc]

Well, that is a bit of an exaggeration but STREAMS was indeed never popular (because of BSD sockets, etc.), which is why it is obsolescent, even if it is interesting. The point I was trying to make is the same one Combuster had made in a previous post (that I originally missed): Many people use the same name, ioctl, for many different routines. Talking about the portability of a non-POSIX ioctl makes as much sense as talking about the portability of kmain.

But it was specified, just not by POSIX.. it was specified in V7 Unix, it was in specified 2BSD/4BSD, and even Linux. There are many such examples of de facto standards in the wild that are looked upon favourably, like BSD's glob() or OpenBSD's strlcpy/strlcat().

I'm not saying that ioctl() requests are portable, but the semantics of the interface is perhaps.. by consensus.

[Combuster]

Well then, by that argument, everybody should use system(), because it's C89+ and POSIX, and therefore even more portable.

[Brynet-Inc]

Well then, by that argument, everybody should use system(), because it's C89+ and POSIX, and therefore even more portable.

Well, you've convinced me. I guess I'll stop using exec*().

[Love4Boobies]

No one talked about not using things---only about not being able to using them portably. That said, you can use both system and exec quite portably in an UNIX environment, as long as the code on the other side is cross-platform. There is no equivalent option for ioctl.