Safer/better equivalent to ioctl?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
AndrewAPrice
Member
Member
Posts: 2300
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Re: Safer/better equivalent to ioctl?

Post by AndrewAPrice »

rdos wrote:If a function is important to support, you provide API functions for it, and if it simply is something fancy a hw manufacturer wants to push, then they can either configure it with environmental variables or do some automatic configuration. Of course, unless the OS team thinks it is something useful that more than one device supports, and then provide a new API for it.
I don't know a solution to every manufacturer inventing their own extensions and somehow keeping everything compatible. Unless there's an industry consortium from the very start that agrees on a common interface, I think at some point, as the OS developer, you see both NVidia and AMD have very similar extension functions, so you create a generic version and add it to GraphicsInterface 1.3 and hope the driver developers implement the new graphics interface.

I mentioned earlier that I'm using my own IDL to specify and generate stubs for communicating with drivers and microservices. If "perception.devices.StorageDevice" doesn't provide a "Rewind Tape" function, IBM could make an "ibm.LtoDevice" interface in a library, the IBM tape driver could implement both "perception.devices.StorageDevice" and "ibm.LtoDevice", and any program that cares about rewinding tapes in an IBM tape drive could depend on IBM's library and get the generated C++ interface for talking to "ibm.LtoDevice".
My OS is Perception.
Post Reply