> Though open(2) does indeed not document this error, it is a documented > POSIX return and it has been possible that this could get returned on > open for a TTY for a very long time. > No it isn't, the current and previous editions of POSIX don't document EIO as a return for open() - are you sure you're not reading the XSI STREAMS specification? :-) That being said, as I discussed above, open() has always apparently returned EIO in Linux for other reasons. We should probably make sure this is documented.
> Yes EIO is not a very intuitive > return but actually they chose a different return code as it does indeed > indicate something different than an EAGAIN might. EGAIN generally meaning > "just do it again" and EIO meaning "this is stuck closing at the moment". > The problem is that EIO is *already* returned from open() to mean "omg, the filesystem/block device is on fire! stop! stop! stop!" > It seems that this is predicated only on your dislike of EIO as a return. > No! You dangerously misunderstand. This is predicated on my discovery that open() can already return EIO for different errors that are catastrophic, and thus code that loops on EIO isn't possible. A different error would mean we could retry in userspace - right now the only option is to fail. -- system services not starting at boot https://bugs.launchpad.net/bugs/554172 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
