Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jan 2005 13:36:18 -0800
From:      Sam Leffler <sam@errno.com>
To:        ticso@cicely.de
Cc:        "Kurt J. Lidl" <lidl@pix.net>
Subject:   Re: ttyd0/cuad0 - why is there still this duality ?
Message-ID:  <41F56A52.1040804@errno.com>
In-Reply-To: <20050124194800.GI628@cicely12.cicely.de>
References:  <20050124083043.GA8729@kukulies.org> <20050124151612.GC628@cicely12.cicely.de> <20050124124250.A27718@pix.net> <20050124180840.GH628@cicely12.cicely.de> <41F548D6.9060409@errno.com> <20050124194800.GI628@cicely12.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote:
> On Mon, Jan 24, 2005 at 11:13:26AM -0800, Sam Leffler wrote:
> 
>>Bernd Walter wrote:
>>
>>>On Mon, Jan 24, 2005 at 12:42:50PM -0500, Kurt J. Lidl wrote:
>>>
>>>
>>>>On Mon, Jan 24, 2005 at 04:16:13PM +0100, Bernd Walter wrote:
>>>>
>>>>
>>>>>On Mon, Jan 24, 2005 at 09:30:43AM +0100, Christoph P. Kukulies wrote:
>>>
>>>Yes, but this way it just works and applications used it for many
>>>years.
>>>
>>
>>Portable modem-aware applications have never used it (speaking as 
>>someone that wrote many modem-oriented applications like tip and 
>>hylafax). I've never found a case where you cannot implement the 
>>equivalent functionality outside the kernel.
> 
> 
> The following scenario:
> Null modem cable and getty on both sides.
> Works fine with any outdialin software in both directions and with
> automatic disconnect on DCD (issued by remote DTR) loss.
> How would you handle this without dual mechanism?
> 

I don't consider this a meaningful setup.  The split device arrangement 
was originally created to do transparent interlock between getty and 
outbound applications.  It's been shown that this can be done well using 
only lock files.

Note that I'm not suggesting one remove the functionality from the 
system though I consider it's value minimal at best.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F56A52.1040804>