Keith Packard wrote: > >> My main concern is with ioctls that aren't interruptible, like >> DRM_IOCTL_VERSION. >> Why should we have a check on those, when they never return -EAGAIN or >> -EINTR? >> That looks bad and will confuse people (new drm developers) to think >> restarting is always needed. >> > > That would require auditing forwards and backwards to ensure that > signals are handled correctly in all existing and new ioctls. Creating a > pattern where every ioctl always loops on EINTR means that new functions > which do receive signals will 'just work' instead of depending on the > developer to carefully analyse their code. > That's exactly the point. We don't want to encourage people to be sloppy about this. If an IOCTL is restartable, the developer should know about this and make sure it's either documented or has a corresponding user-space library function that does the right thing. I'm pretty sure we can rely on the existing core drm IOCTLs to be signal-safe without auditing, as we've never seen any such problems with other drm-command-submitting X servers (for example openChrome and Poulsbo). Now _if_ the existing drm IOCTLS are returning -EINTR without being aware of it, they probably also need a fixed cleanup path, and rather than masking this we should fix it.
/Thomas ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
