On Thu, Jan 25, 2007 at 06:09:33PM +0100, Dominique Larchey-Wendling wrote: > Even tough such an event would have a low probability to occur > if the 2 ioctl are close enough, it is still possible. This is > a race condition (outside the kernel but possibly locking some > process). > > I propose the introduction of a new ioctl to solve this race, > implemented through the NEW function uart_wait_new_status associated > to a NEW ioctl. > > The idea is that this new call would detect a change not compared > to the status at the beginning of the call but compared to some > previously recorded state. This way, the new ioctl would not > miss a status change, even if it occurs before the call to the > ioctl. You're right that this is a technical flaw in TIOCMIWAIT. When it was originally implemented, it was done to retain compatibility with older implementations in other OS's. The question is why do you need such functionality? The only way to implement what you propose would be pass a structure containing the previous counts into your proposed new ioctl(), which won't be well received by the folks who have to maintain 32/64-bit translation tables for ioctl's for use by supporting architectures that have to support 32 and 64 bit ABI's simultaneously. Because of this issue some folks have proposed killing off ioctl's entirely, which is probably not the right answer, but the fact remains that adding new ioctl's that require passing in pointers to arbitrary data structures is definitely not going to be well received. So what are you actually trying to *do*? Is this just to fix a theoretical shortcoming? What does your application really need to do, and perhaps there's a another way we can address it with perhaps a cleaner interface. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
