[Bug 1001466] /dev/null serial driver

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