ttyd0/cuad0 - why is there still this duality ?

Sam Leffler sam at errno.com
Mon Jan 24 11:13:02 PST 2005


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:
>>>
>>>>Just a question. Maybe it isn't true but to me it seems there
>>>>is still this duality between ttyd and cuad serial devices.
>>>>
>>>>Why is that? I'm just asking because someone I was talking with 
>>>>about modems an comm programs was 'criticising' this fact
>>>>in FreeBSD "while other systems long have abandoned this dualism"?
>>>
>>>Because modems are still used for dial-in and dial-out.
>>>tty handing out to getty and cua to the dial out process.
>>>Moreover this handling was recently added for usb serials under
>>>-current.
>>>If other systems loose features - well it's their problem.
>>
>>That's a very limited way of looking at the functionality.  If you
>>want to support the functions of both dialin and dialout on one
>>serial port, there doesn't need to be more than one kernel device.
>>Just because support for this got hacked into 4.2BSD in a gross
>>manner doesn't mean that there isn't a better of doing this.
> 
> 
> You still have the option to just ignore existenz of tty* devnodes.
> 
> 
>>Having seperate dialout and dialin devices really are just a kludge
>>for having the kernel doing locking that could be done in userland
>>code.
> 
> 
> tty* vs cua* is more than just locking.
> 
> 
>>Just because FreeBSD does this the same way it's been done on
>>BSD-ish systems for the last 15 years doesn't mean there isn't a
>>better way of doing it.
> 
> 
> 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.

	Sam


More information about the freebsd-hackers mailing list