[uClinux-dev] minicom from uclinux

David McCullough davidm at snapgear.com
Wed Mar 26 06:17:27 EST 2003

Jivin Andrey Butok lays it down ...
> Hello
> David McCullough wrote:
> >>tip does set the appropriate flags in the driver.  If your driver does
> >>not support xon/xoff or rts/cts handshaking then that is another thing.
> Yes I am fully agree with you. The "tip" just only sets flags of lower
> driver => the "tip" does not handle signals of flow control (as I tried to
> say before!!). So it should be implemented by the "mcfserial". Is not it?

Yes,  mcfserial does implement the flow control functions.

> But Greg Ungerer wrote:
> >>Works for me. Off-course flow control relies on both ends
> >>of the conection being setup to do the same thing. But I
> >>use flow control with the mcfserial ports a lot (mostly
> >>with pppd and modems) and it works fine.
> Yes with using "pppd" , it works!!. So it the signals of the Flow Control
> are handled by the application (in this case "pppd"), the "mcfserial" does
> not do it?

No,  mcfserial does it,  pppd does the same thing as tip and sets the
appropriate flags for the flow control you want.  Look in sys-linux.c.

> So please give me the direct answer whose is this job?
> 1) The applications ( like "tip", "minicom", "pppd" etc)

The application set the flags (like tip and pppd do)

> 2) Low level drivers ( like "mcfserial")

The driver performs the kind of flow control it has been asked to do by
the application.

> 3) Both
> 4) No body
> 5) Somebody else
> 6) Or who wants (no rules)?

There are no hard and fast rules.  If you want to write an application that
does the flow control itself then you can,  but it will never be as good as
driver implemented flow control.

The best thing to do is to ask the driver to do it for you,  as tip and
pppd do,


David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

More information about the uClinux-dev mailing list