Re: OpenBSD Foundation 2014 Fundraising Campaign.
On 4/10/14, Bob Beck b...@openbsdfoundation.org wrote: The Foundation will continue to strive to improve its financial resources, and hopes to be able to provide further support to the projects in the future. Please continue to contribute! Where can I read your financial reports?
Re: termios VMIN VTIME
On 4/4/14, Philip Guenther guent...@gmail.com wrote: The original poster has already be pointed to the POSIX spec and had it explained that OpenBSD won't be changing this behavior as long as it's in POSIX. I didn't ask OpenBSD for code. OpenBSD management seems defensive, perhaps paranoid, that everyone is a beggar demanding code. Relax. I can make the changes I need. If I publish them or not, depends on whether anyone else is interested. That's why I posted, to see if anyone else is interested. Whether it's in POSIX, or not, is beside the point. There many BSD extensions, of all kinds, not in POSIX. At this point, there's nothing OpenBSD-related left: *productive* discussion of changing the behavior should be on the austin-group (i.e, POSIX) mailing list The Austin group won't care until someone has a working implementation. It can be done by overloading VERASE (ignored in raw mode). Its value could be treated as bit flags that change the semantics of VTIME. But if there is little or no interest here, I will look elsewhere.
Re: termios VMIN VTIME
On 4/4/14, Steve Williams st...@williamsitconsulting.com wrote: The POSIX writers erred by making VTIME an interbyte timer. What real life problem are you trying to solve? Theory of operation. Why do you need to have 250 bytes in the returned buffer? Same principle as a 16550 UART FIFO timeout. Is it important to have a steady 11 cps in the other situation? Maybe. Depends on what's attached to the serial port. Have you considered non-blocking IO? Using select or some other equivalent to determine if there is data available on the port prior to the read? Non-blocking select() returns for every byte. This hammers the CPU at high data rates. It's equivalent to blocking I/O with raw mode defaults (VMIN = 1 and VTIME = 0). Hammering the CPU is what I want to avoid. But at the same time, I want to eliminate any worst case, such as the 11 cps, 20 second delay. Maybe your application is mundane, and your data stream is randomly timed, such that an interbyte timer is good enough to avoid most delays. But ignoring the theory of operation and its pitfalls can make a system fail at the worst possible time; not what you want in a life critical situation. Serial communications have been around since the dark ages I was writing code 20+ years ago to talk to RS-232 (a very un-standard standard). There are many ways to solve the same problem... With DOS you have complete control. With POSIX systems the termios interface can be a hindrance.
Re: termios VMIN VTIME
On 4/4/14, John D. Verne john.ve...@gmail.com wrote: The meaning of VMIN, VTIME change depending on if they are non-zero or not. VTIME is not always an inter-character timer I know. but they way you are using it, it is. Yes, POSIX case A: MIN0 and TIME0. Case B, MIN0 and TIME=0, is useless if MIN 1. A call to read() or select() may block forever, even though data is in the buffer. Raw mode default (MIN = 1) is the only reason I would use case B. But then, read() returns for every byte, and it's CPU hammer time. Both case C, and case D, may return a count of 0. Since you can't tell the difference between that 0, vs. end-of-file 0, both are useless to me. Case A is the only one that avoids hammering the CPU. But at 11 cps, a 20 second delay may be unacceptable. After considereing the possibilities, I see a need to extend the semantics of VTIME. I need a bit flag to make it an overall timer, and another flag to make the granularity hundredths of a second, instead of tenths.
Re: termios VMIN VTIME
On 4/2/14, Mihai Popescu mih...@gmail.com wrote: Dude, what the hell are you trying to do? Just explain in plain words here. I am interested in working with rs232 and i wasted my time reading and wainting for your damn problem. a) Set raw mode. b) Set VMIN = 250 and VTIME = 1. c) Set port speed to 115200. d) Read data from the serial port. e) Have a device (or program) send data to the serial port, at a steady rate of 11 cps. f) Notice a 20 second delay before read() returns. Your sending device appears to have stalled, though it has not. The problem is, VTIME is an interbyte timer. At 11 cps and VTIME = 1, it never expires. You wait 20 seconds for VMIN to kick in, before read() returns. Unfortunately, POSIX provided no option to make VTIME an overall timer. VMIN must not exceed MAX_INPUT (255 on my linux test box). So VMIN must be = 255 (even though an integer holds the value). Now suppose VTIME was an overall timer, not an interbyte timer. In 0.1 seconds at 115200, you can transfer about 1100 bytes. At that speed, VMIN will kick in before the timer expires, and read() will return with approx. 250 bytes. If you get a block 250 bytes, you will never wait more than 0.1 seconds for it, even in the worst case, a steady 11 cps. The POSIX writers erred by making VTIME an interbyte timer.
termios VMIN VTIME
On stackoverflow I said: http://stackoverflow.com/questions/20154157/termios-vmin-vtime-and-blocking-non-blocking-read-operations/22771908#22771908 Any thoughts on fixing the design, in favor or opposed?
Re: termios VMIN VTIME
On Mon, Mar 31, 2014 at 11:17 PM, Philip Guenther guent...@gmail.com wrote: You haven't convinced me the design needs fixing, nor have you proved that the goal that you (sorta) describe can't already be solved with the existing APIs. What problem are you trying to solve? a) set VMIN = 250; don't read() very small blocks during bulk transfers b) set VTIME = 1; never wait more than 0.1 seconds for read() to return I found a worst case scenario that violates (b). I proved it by experiment and clearly described it. Not sorta. With the existing design you cannot eliminate the worst case. But maybe I'm the only one who cares.
Re: termios VMIN VTIME
On Mon, Mar 31, 2014 at 11:52 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: In the future, please submit concise reports rather than a link to something vague which is part of a long conversation on some site out there. It will indicate you are serious. I may do that. Perhaps VMIN and VTIME were designed back in the day to make multi-share performance of machines work better, not to satisfy timing-grained servicing. Maybe they just overlooked the worst case. Anchoring the timer at the first byte, instead of letting it roll and restart with each new byte, would eliminate the worst case. I'd suggest approaching the Austin Group. At worst, you'll waste your own time. At best, you'll waste their time. At least improve your approach. I could submit a detailed report to the list, but if I'm the only one who cares about it, why bother. I can attempt a local hack and keep it to myself. I'm not attacking OpenBSD; I just wondered if anyone else might be interested. The Austin Group? I doubt they are.
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 12:23 AM, Philip Guenther guent...@gmail.com wrote: I *sounds* like the problem you're trying to solve** is some thing like I want to efficiently read data from a serial line, returning whenever at least 250 bytes are available or when more then 0.1s has passed. If no data is received, it should still return after 0.1s. No, read() should not return 10 times per second when there is no data. It must depend on VMIN and VTIME. When 1 byte becomes available, the 0.1 timer starts, and further bytes do not restart it. A call to read() returns when VMIN is satisfied, or the timer expires by reaching 0.1. Tthe timer must not be interbyte, restarted by further bytes. The worst case I described continually resets an interbyte timer, pushing it into the future, until VMIN overcomes the effect. That can take up to 20 seconds. Is that an accurate description of what you're actually trying to do? Do you see the difference between that description and what you wrote? Your wording is different. But superior? No so sure. As for the problem, I'm not deaf to alternate solutions. Do you have one? something you're really trying to do? Your posts make it sound like this is a hypothetical and not something you're actually facing. Is it always safe to ignore hypothetical problems?
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 1:18 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: Are you saying OpenBSD does it wrong, or that all the operating systems do it wrong? I tested Linux and OpenBSD. Both wrong. The termios man pages from NetBSD and FreeBSD are identical to OpenBSD. So I expect they're wrong too.
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 1:39 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: I suspect they all follow an official specification. Careful test code compared to the specification would decide. It might show them all to be right, leaving the obvious conclusion about who is wrong. To test it, I used two Perl scripts, sender and receiver, a two port serial card, and a null modem cable. I controlled the sending rate of 11 cps by calling syswrite with 1 byte, in a loop with a 0.09 second pause between iterations. You think they went to all that trouble? My tests say the problem is real. Whether it's important or not, is a matter of opinion. Believe what you will.
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 2:39 AM, Philip Guenther guent...@gmail.com wrote: Your question is why haven't OS developers done what I think is right? The answer to that question is because the POSIX standard says we shouldn't, and is quite clear about this. Show me where POSIX says VTIME must be an interbyte timer. When it looks like the hypothetical application problem can be solved using the full UNIX API, I'll stop worrying about it and worry about real problems. You believe a solution exists, but you can't tell me what it is.
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 2:12 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: your cute little nickname should have hinted that you don't have a mature understanding of the world. Thanks for the psychoanalysis, doctor. Is your advice free, or do you charge for it?
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 3:00 AM, Philip Guenther guent...@gmail.com wrote: Show me where POSIX says VTIME must be an interbyte timer. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap11.html#tag_11_01_07 I missed that during my search. POSIX says so. OK. And you *still* haven't provided a clear answer to what problem are you trying to solve? that doesn't assume the answer. You understood the problem well enough to restate it in your own words. I'm ready to hear your solution.
Re: termios VMIN VTIME
On Tue, Apr 1, 2014 at 3:37 AM, Philip Guenther guent...@gmail.com wrote: you stated that my description was wrong and not what you were looking for on at least one point of behavior. If by that, you mean this: If no data is received, it should still return after 0.1s. No, read() should not return 10 times per second when there is no data. It must depend on VMIN and VTIME. I didn't mean you were wrong. The action of no data can vary, depending the combination of VMIN and VTIME. I was clarifying what I wanted. But whatever. I would probably do it by clearing VMIN and VTIME and poll()ing for input with no timeout. Once that returns that there's data available, set VMIN to the desired value and poll() again with the desired timeout. When that returns clear VMIN and do the read(). That perfectly matches the spec inside my head; if it doesn't match the spec inside your head then you should have stated what you were trying to do in your last half dozen messages. I never considered altering VMIN in flight. My application proxies sockets to serial ports in a select() loop, and I want to keep it simple. But thanks for the idea, I will ponder it. Enough wanking. Time to get back to solving *real* problems. It's not hypothetical to me.
