This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001466] /dev/null serial driver
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Thu, 16 Feb 2012 12:20:11 +0000
- Subject: [Bug 1001466] /dev/null serial driver
- Auto-submitted: auto-generated
- References: <bug-1001466-104@http.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=1001466
--- Comment #5 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-16 12:20:05 GMT ---
(In reply to comment #4)
[snip]
> Well the name '/dev/null' is known for decades and for any *nix
> developer this name tells what it does, as posix/opengroup use this
> name.
But it is not terminal/teletype/console/serial, etc. From your source
(Open Group)
/dev/null
An infinite data source and data sink. Data written to /dev/null
shall be discarded. Reads from /dev/null shall always return
end-of-file (EOF).
(EOF) - END OF *FILE*. As I said /dev/null is a special FILE. But,
/dev/null is not TTY device (not terminal):
Check in Python
>>> import os
>>> fd=os.open("/dev/null", os.O_RDWR)
>>> os.isatty(fd)
False
Check in C
% cc -xc - <<EOF
> main(){printf("/dev/null is %s
tty\n",isatty(open("/dev/null","r"))?"a":"not");}
EOF
% ./a.out
/dev/null is not tty
[snip]
> AFAIK there is no specific requirements regarding the implementation,
> only the name and the result it must provide. Using the serial
> abstraction seemed fine to me since most often /dev/null is used to
> sink data coming from a byte stream. I suppose that serial devices are
> embedded in all targets, at least for diag_printf(), that why I placed
> it here so there is no need to bring other components.
If your concern is diagnostic output only (diag_printf()), you ain't
gonna need it. I mean /dev/null. The eCos diagnostic routines do not use
devfs. Look
infra/current/src/diag.cxx:93
HAL_DIAG_WRITE_CHAR() macro is defined in hal_diag.h as
#define HAL_DIAG_WRITE_CHAR(_c_) hal_if_diag_write_char(_c_)
Further
hal/common/current/src/hal_if.c
Using CYGACC_CALL_IF_* macros you can (re-)assign diagnostic channel
anywhere, for example, to some auxiliary COMM channel (black-hole).
Excellent example how to to deal with eCos COMM channels is RedBoot
redboot/current/src/main.c
redboot/current/src/io.c
Look around mon_write_char() there. So, (IMHO) in the simplest case you
would just use diag_init_putc() to solve your issue.
More on eCos VV & COMMS channels
http://ecos.sourceware.org/docs-latest/ref/hal-porting-guide.html
http://ecos.sourceware.org/docs-latest/ref/hal-calling-if.html
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.