Bug 83265
| Summary: | TIOCMIWAIT semantics changed in 2.4.18-19.7 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | David J. Schwartz <davids> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-02-01 22:03:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
TIOCMWAIT has always taken "event" not &event. Is it possible that your code worked before because event sat at an address that had the right bits set to make it apparently work ? I suppose that's possible, but there's two reasons I don't think it's likely. First, several programs of mine that worked on the old kernel now don't work and do work with this change. It's hard to imagine how a kernel version change would affect the memory layout of the processes that way. Second, I've found web references both ways. http://www.mbsi.ca/pipermail/hsflinux/2002q2/000103.html http://www.microgate.com/products/sllinux/Programming.txt I'm going to look at the source code for earlier kernels and look at the TIOCMIWAIT implementation. I'm fairly certain I'll find it takes a pointer to the flags in the earlier implementations. Sorry, that reference should be: http://www.mbsi.ca/pipermail/hsflinux/2002q2/000094.html I checked the kernel source and it seems that you're right. I guess some other change made the code that previously happened to work (because the address happened to have the 0x40 bit set in it) no longer work. There doesn't appear to be any authoritative or even quasi-authoritative documentation for this ioctl and the examples I've found are split between the correct and incorrect form about 3 to 2 in favor of the correct format. I'll go with the majority, especially where the source agrees. Thanks for the prompt response and sorry for the false alarm. I'm going to send off emails to others having reliability problems with TIOCMIWAIT that are probably due to their addresses not happening to have the right bits set. |
Description of problem: The semantics of the TIOCMIWAIT IOCTL seem to differ between 2.4.18-19.7 and previous kernel versions. An incompatible API change is inappropriate between minor kernel version changes. The previous semantics of TIOCMIWAIT were: int ret; int events; int fd; ret=ioctl(fd, TIOCMIWAIT, &events); The new semantics are: ret=tioctl(fd, TIOCMIWAIT, events); While the new semantics are, arguably, more logical, all code that uses TIOCMIWAIT is broken by this change. There doesn't seem to be any reasonable way to probe for this change, so code that uses TIOCMIWAIT has to be built for one kernel version or the other. This change is of too great a scope to make between minor kernel revisions and was probably made by accident. Version-Release number of selected component (if applicable): 2.4.18-19.7 How reproducible: 100% reproducible. Steps to Reproduce: 1. Compile any program that uses TIOCMIWAIT 2. Try it on both old and new kernels 3. Compare results Actual results: TIOCMIWAIT works if you pass an address as the last parameter in new kernels and if you pass the value as the last parameter in older kernels. Expected results: They should be the same, this is too great a change to make between minor kernel versions. Additional info: I'm curious if this change was an error and the old semantics are supposed to be there, or if it's a semantics change that was made deliberately and included in the minor update by mistake, or if it was a change deliberately made between minor kernel releases.