[Bug 1001466] New: /dev/null serial driver

[Bug 1001466] New: /dev/null serial driver

[bugzilla-daemon]

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

           Summary: /dev/null serial driver
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Try to mimick /dev/null. (inspired by loop serial driver.)

$ tar tf devnull.tar
null/
null/current/
null/current/cdl/
null/current/cdl/ser_null.cdl
null/current/src/
null/current/src/null_serial.c
null/current/ChangeLog
null/current/doc/
null/current/doc/null_serial.sgml
$

Comments welcome, maybe the semantics aren't close enough to Un*x but it should
do the job for most cases. The doc may need to be rewritten?

  Bernard

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #1 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-01-27 19:14:07 GMT ---
Created an attachment (id=1534)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1534)
/dev/null

Attachment did not make it when I entered the patch...

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #2 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-15 13:46:54 GMT ---
Created an attachment (id=1583)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1583)
ecos.db entry

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

Bernard Fouché <bernard.fouche@kuantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1534|/dev/null                   |/dev/null as a tar file
        description|                            |
   Attachment #1534|1                           |0
           is patch|                            |

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-15 20:45:18 GMT ---
On Comment #0
> Try to mimick /dev/null. (inspired by loop serial driver.) Comments
> welcome, maybe the semantics aren't close enough to Un*x but it should
> do the job for most cases. The doc may need to be rewritten?

It seemed to me your interpretation of /dev/null will arise some
confusions for some users. Below are mine.

Mess #1

  I would avoid the same mimic (and naming). In UNIX-like operating
  systems, /dev/null is a special *file* and not a serial device.

  % stty -aF /dev/null
  stty: /dev/null: Inappropriate ioctl for device

As you can see /dev/null is not some terminal line (serial device).
Well, eCos != *nix, but, I would avoid the ability to configure the
/dev/null as a serial device under eCos.

Mess #2

  A read on /dev/null would not block process (thread), it does return
  EOF, and you offer in your documentation to enter an ability of the
  blocking read on /dev/null as an option.

Mess #3

  IMO, if anyone will see those words together in CDL (I mean 'serial'
  and 'null'), under eCos dev/serial/null, then he would think, Great!
  There is 'nullmodem' device in eCos! Come check my guess

    http://www.google.com/search?q=%2Bserial+%2Bnull 

  And after reading your documentation, they will think, Nope! They
  provide something very special (special null device :-)

BUT

I do not want to break your idea. IMHO, the main mess here is naming and
your free interpretation of /dev/null. You try to implement some serial
device like a "tear off" nullmodem, but what is bad with a "nullmodem"
abstraction for your purposes? And eCos serial loop driver (as you could
see) is a half of nullmodem itself.

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #4 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 09:54:21 GMT ---
(In reply to comment #3)
> [snip]
> As you can see /dev/null is not some terminal line (serial device).
> Well, eCos != *nix, but, I would avoid the ability to configure the
> /dev/null as a serial device under eCos.

Opengroup says
(http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap10.html):

/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).

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.

> 
> Mess #2
> 
>   A read on /dev/null would not block process (thread), it does return
>   EOF, and you offer in your documentation to enter an ability of the
>   blocking read on /dev/null as an option.

I can change this

> 
> Mess #3
> 
>   IMO, if anyone will see those words together in CDL (I mean 'serial'
>   and 'null'), under eCos dev/serial/null, then he would think, Great!
>   There is 'nullmodem' device in eCos! Come check my guess
> 
>     http://www.google.com/search?q=%2Bserial+%2Bnull 
> 
>   And after reading your documentation, they will think, Nope! They
>   provide something very special (special null device :-)

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
> 
> I do not want to break your idea. IMHO, the main mess here is naming and
> your free interpretation of /dev/null. You try to implement some serial
> device like a "tear off" nullmodem, but what is bad with a "nullmodem"
> abstraction for your purposes? And eCos serial loop driver (as you could
> see) is a half of nullmodem itself.

I just need to sink data, I don't need a FIFO that copies data between two
points, I don't need a cross-over serial cable. I need /dev/null :-)

Anyway the patch is here, I can rework it. It seems there is more work in
defining what to do than real work, there are probably already more characters
in this discussion than in the driver itself ! My goal was just to provide to
others a hack I found useful in my current developments.

-- 
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.

Re: [Bug 1001466] /dev/null serial driver

[Grant Edwards]

On 2012-02-16, bugzilla-daemon@bugs.ecos.sourceware.org <bugzilla-daemon@bugs.ecos.sourceware.org> wrote:

>> As you can see /dev/null is not some terminal line (serial device).
>> Well, eCos != *nix, but, I would avoid the ability to configure the
>> /dev/null as a serial device under eCos.
>
> Opengroup says (http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap10.html):
>
> /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).

That makes no sense.  It not an infinite data source if a read always
EOF.

> 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.

The issue is that "byte stream" and "serial device" are not
equivalent.  A "serial device" supports read/write like a byte stream,
but it also includes another API that.  On Unix, /dev/null isn't a
serial device, and that's why using that name for a serial device on
eCos is a possible source of confusion.  Historically, there has never
been a "null" serial device on Unix systems (that I know of).

> 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.

I don't think anybody is arguing that a null serial device is a bad
idea, just that it might be better to use a name other than /dev/null.

>> Mess #3
>> 
>>   IMO, if anyone will see those words together in CDL (I mean 'serial'
>>   and 'null'), under eCos dev/serial/null, then he would think, Great!
>>   There is 'nullmodem' device in eCos! Come check my guess
>> 
>>     http://www.google.com/search?q=%2Bserial+%2Bnull 
>> 
>>   And after reading your documentation, they will think, Nope! They
>>   provide something very special (special null device :-)
>
> 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.

Except on Unix, /dev/null is not a serial device (it's not a tty). 
It's a plain vanilla character device.

> I just need to sink data, I don't need a FIFO that copies data
> between two points, I don't need a cross-over serial cable. I need
> /dev/null :-)

If all you need is /dev/null, why the extra work to make it a serial
device?

-- 
Grant Edwards               grant.b.edwards        Yow! I'm totally DESPONDENT
                                  at               over the LIBYAN situation
                              gmail.com            and the price of CHICKEN
                                                   ...

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #6 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 14:20:30 GMT ---
My issue is to keep in the app on the field things like
fprintf(DebugStream,...) and be able to activate/deactivate the debug messages
without modifying the app, and without adding things like 'if(DebugOpened)'
before each use of DebugStream.

This way I can use a serial port for the app and when debug is needed, I
disconnect the connected device on the serial port, connect instead a terminal
emulator, activate debug, check the debug messages and then go back to full app
mode afterwards.

If I use:

if(DebugOpened)
  fprintf(DebugStream,...)

Then I also need

if(!DebugOpened)
  fprintf(NotADebugStream,...)

While with this driver I can do:

#if DEBUG
fprintf(DebugStream,...)
#endif
fprintf(NotADebugStream,...)

When I need to deactivate the messages, I fclose(DebugStream) and do
DebugStream=fopen("/dev/null").

When I need the debug messages back I do the same fclose() but fopen() to some
/dev/serX. In my mind it's like sending stderr to /dev/null or sending it to
some output device, that's why I named this fake driver '/dev/null'.

Performance isn't an issue here, it's convenience first during app tests (that
can last for months) on a target that uses all serial ports.

I can't add enable/disable config keys to serial.c since this would completely
switch on or off the uart: I always need the uart but I need to select what
stream is feeding it.

Maybe the proper solution is in the stdio lib? Or rename the driver
/dev/ser_void to avoid semantics confusion with /dev/null?

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilijak@siva.com.mk

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-16 15:05:15 GMT ---
(In reply to comment #5)
> (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
> 

Shall it really be a problem to use name /dev/null? I don't think so, at least
to me first association with /dev/null is the null device. If it sinks on write
and returns EOF on read it should be enough.

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #8 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 15:38:36 GMT ---
(In reply to comment #7)
> Shall it really be a problem to use name /dev/null? I don't think so, at least
> to me first association with /dev/null is the null device. If it sinks on write
> and returns EOF on read it should be enough.

In poll mode, serial.c calls (funs->getc)(chan) and consider that a character
is always obtained when the function returns: getting EOF in that case does not
seem possible.

Now who will try reading /dev/null in poll mode? Maybe in this case the driver
should refuse to compile (#error "/dev/null doesn't support poll mode")?
However one may use poll mode but only write to /dev/null. Or CYG_FAIL() could
be called in poll mode if /dev/null is read?

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-16 15:57:43 GMT ---
(In reply to comment #6)

> Maybe the proper solution is in the stdio lib?

My check for eCos fopen("/dev/null", ...) from the box

The eCos template:

  cdl_configuration eCos {
      template    default ;
      package CYGPKG_IO_FILEIO current ;
  };

Example of GDB session:

  % arm-eabi-gdb -q examples/hello
  (gdb) target remote /dev/ttyUSB0
  Remote debugging using /dev/ttyUSB0
  0x00002d48 in ?? ()
  (gdb) load
  Loading section .rom_vectors, size 0x40 lma 0x81008000
  Loading section .text, size 0x9714 lma 0x81008040
  Loading section .rodata, size 0x344 lma 0x81011754
  Loading section .data, size 0x484 lma 0x81011a98
  Start address 0x81008040, load size 40732
  Transfer rate: 3 KB/sec, 299 bytes/write.
  (gdb) b main
  Breakpoint 1 at 0x81008534: file hello.c, line 7.
  (gdb) b exit
  Breakpoint 2 at 0x81010ad0: file
/home/sg/repo/ecos-hg/packages/language/c/libc/startup/current/src/exit.cxx,
line 74.
  (gdb) cont
  Continuing.
  [New Thread 2]
  [Switching to Thread 2]

  Breakpoint 1, main () at hello.c:7
  7        FILE           *fh = fopen("/dev/null", "r+");
  (gdb) l
  2    #include <stdlib.h>
  3    
  4    int
  5    main(void)
  6    {
  7        FILE           *fh = fopen("/dev/null", "r+");
  8        fprintf(stdout, "Hello, eCos world! (at stdout)\n");
  9        fprintf(fh, "Hello, eCos world! (at /dev/null)\n");
  10        fclose(fh);
  11        fprintf(stdout, "Bye! (at stdout)\n");
  (gdb) cont
  Continuing.
  Hello, eCos world! (at stdout)
  Bye! (at stdout)

  Breakpoint 2, exit (status=0)
      at
/home/sg/repo/ecos-hg/packages/language/c/libc/startup/current/src/exit.cxx:74
  74    exit( int status )
  Current language:  auto; currently c++
  (gdb) 

And what you get?

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #10 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 16:25:43 GMT ---
(In reply to comment #9)
> (In reply to comment #6)
> 
> > Maybe the proper solution is in the stdio lib?
> 
> My check for eCos fopen("/dev/null", ...) from the box
> 
> The eCos template:
> 
>   cdl_configuration eCos {
>       template    default ;
>       package CYGPKG_IO_FILEIO current ;
>   };
> 
> Example of GDB session:
> 
>   % arm-eabi-gdb -q examples/hello
>   (gdb) target remote /dev/ttyUSB0
>   Remote debugging using /dev/ttyUSB0
>   0x00002d48 in ?? ()
>   (gdb) load
>   Loading section .rom_vectors, size 0x40 lma 0x81008000
>   Loading section .text, size 0x9714 lma 0x81008040
>   Loading section .rodata, size 0x344 lma 0x81011754
>   Loading section .data, size 0x484 lma 0x81011a98
>   Start address 0x81008040, load size 40732
>   Transfer rate: 3 KB/sec, 299 bytes/write.
>   (gdb) b main
>   Breakpoint 1 at 0x81008534: file hello.c, line 7.
>   (gdb) b exit
>   Breakpoint 2 at 0x81010ad0: file
> /home/sg/repo/ecos-hg/packages/language/c/libc/startup/current/src/exit.cxx,
> line 74.
>   (gdb) cont
>   Continuing.
>   [New Thread 2]
>   [Switching to Thread 2]
> 
>   Breakpoint 1, main () at hello.c:7
>   7        FILE           *fh = fopen("/dev/null", "r+");
>   (gdb) l
>   2    #include <stdlib.h>
>   3    
>   4    int
>   5    main(void)
>   6    {
>   7        FILE           *fh = fopen("/dev/null", "r+");
>   8        fprintf(stdout, "Hello, eCos world! (at stdout)\n");
>   9        fprintf(fh, "Hello, eCos world! (at /dev/null)\n");
>   10        fclose(fh);
>   11        fprintf(stdout, "Bye! (at stdout)\n");
>   (gdb) cont
>   Continuing.
>   Hello, eCos world! (at stdout)
>   Bye! (at stdout)
> 
>   Breakpoint 2, exit (status=0)
>       at
> /home/sg/repo/ecos-hg/packages/language/c/libc/startup/current/src/exit.cxx:74
>   74    exit( int status )
>   Current language:  auto; currently c++
>   (gdb) 
> 
> And what you get?

Excellent! Just need some documentation and then /dev/null can go to itself ;-)

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #11 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-16 16:37:05 GMT ---
(In reply to comment #10)

[snip]

> > And what you get?
> 
> Excellent! Just need some documentation and then /dev/null can go to
> itself ;-)

So, let's 

  Bug 1001466 > /dev/null

:-)

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #12 from Bernard Fouché <bernard.fouche@kuantic.com> 2012-02-16 16:48:39 GMT ---
(In reply to comment #11)
> (In reply to comment #10)
> 
> [snip]
> 
> > > And what you get?
> > 
> > Excellent! Just need some documentation and then /dev/null can go to
> > itself ;-)
> 
> So, let's 
> 
>   Bug 1001466 > /dev/null
> 
> :-)

Please change bug's state only when there is some doc about the trick you used,
and that doc uses the term '/dev/null': this will avoid losing time to some
other users if they are looking for a solution to the absence of /dev/null in
eCos.

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-16 17:21:00 GMT ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > 
> > [snip]
> > 
> > > > And what you get?
> > > 
> > > Excellent! Just need some documentation and then /dev/null can go
> > > to itself ;-)
> > 
> > So, let's 
> > 
> >   Bug 1001466 > /dev/null
      ^^^^^^^^^^^^^^^^^^^^^^^

Excuse my '... > /dev/null' jargon:
http://en.wikipedia.org/wiki//dev/null

> Please change bug's state only when there is some doc about the trick
> you used, and that doc uses the term '/dev/null': this will avoid
> losing time to some other users if they are looking for a solution to
> the absence of /dev/null in eCos.

Good approach. I'll change the state to 'NEED INFO'.

As for my guess and test in GDB. I decided to check that example when I
saw in ecos.ecc:

  cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE {
      # Default value:  CYGDAT_IO_SERIAL_TTY_CONSOLE ?
CYGDAT_IO_SERIAL_TTY_CONSOLE : "\"/dev/null\"" 
  }

Hm, /dev/null? And I was looking for what will happen then.

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |sergei.gavrikov@gmail.com
     Ever Confirmed|0                           |1

--- Comment #14 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-02-17 06:17:09 GMT ---
A while keep bug 1001466 as a memo.

-- 
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.

[Bug 1001466] /dev/null serial driver

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

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

--- Comment #15 from Jonathan Larmour <jifl@ecoscentric.com> 2012-02-18 19:38:26 GMT ---
I've only just woken up and noticed this patch. I don't think it should be
hooked into the serial driver. It's unnecessary and if someone wants /dev/null
and doesn't need a serial driver it will pull in lots of unnecessary baggage.
It will also be unnecessarily CPU intensive as it will be working a byte at a
time with the serial layer.

I think it should be implemented directly as a CYGPKG_IO device driver. NB it
will still work with libc's stdio with or without the fileio package too.

Jifl

-- 
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.