[Bug 21968] select does not work on stdin

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-11-16 03:14:10 GMT ---
(In reply to comment #3)
> This seems like a pretty bad bug to be categorized as "low" priority?!?
> 
> Use case is: people want diag/log output to a serial port, but also want to be
> able to fire up a shell command processor when users put in a special
> sequence...this should be a fairly common thing to do :-P
> For workarounds, we've tried this:
> - tried using select() then getchar()...selects apparently are broken because
> it sometimes says a character is ready but it isn't, so it goes to the getchar
> and locks up the entire scheduler (locking up the console task would have been
> fine, but no....)-:

Where is it locked? What's the backtrace when you interrupt it from a debugger?

> - tried using select() and then read() to bypass the buffering...same weird
> behavior
> - use direct calls to the HAL COMM_IF_GETC_TIMEOUT etc. functions...these don't
> block but also returns maybe 1% of characters typed in

That seems to tell me that you're trying to use select with a HAL diagnostic
channel as your stdin. Don't do that. The HAL diagnostic channel is there for
debug only for simple output. It is polled only with interrupts off. Use a
proper serial driver, or if this is for user terminal use, then a tty wrapper
around a serial driver (e.g. /dev/tty0 for /dev/ser0 - look at the serial
docs).

> - tried to use configtool to tell eCos not to use that port for diag output,
> but apparently, you can't just point it at /dev/null or a non-existent serial
> port :-P

If you don't want to use that channel at all, then don't try and use it for
input or output surely!

> - tried enabling termios in eCos, but the ioctl call to get the number of
> characters queued doesn't work

This should work without termios, no need to complicate things by including it.

What port is this? Since this is an 11 year old bug report you've added to, I'm
tempted to believe it isn't an Intel StrongARM Assabet board.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.