Since the UDI environment is currently mostly in a “layered” onto existing OS facilities, doesn that hurt performance?
Not really. There are certainly facilities that could benefit from tighter integration into the host OS but we didn’t do so in the name of risk management during the prototyping phase. Because we were often developing the specification, the drivers, and the environment simultaneously, we tried to avoid debugging the host OS at the same time. There were some tradeoffs involved, but now that we’ve reached stability and reasonable performance, a tighter integration is practical to consider. We also expected developer resistance to requiring patched or custom kernels before using the environment. As such, we worked hard to provide an environment that worked on stock kernels of our target OSes and were willing to make some tradeoffs. • If the environment uses native interfaces behind the scenes, how can it be faster than native interfaces? As one example, we allow instance independence which isn’t common in many existing driver models. By placing locks only around the entry points into a re
Related Questions
- In the case where existing facilities are to be altered and renovated, does the current status of the space need to be described?
- Since the UDI environment is currently mostly in a "layered" onto existing OS facilities, doesn that hurt performance?
- What is the best way to hold people accountable in an environment that doesn reward exceptional performance?
