linux-kernel - Re: should RTS init in serial core be tied to CRTSCTS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3irdaywwd.fsf@maximus.localdomain>
Date:	Fri, 09 Mar 2007 21:39:14 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	"Tosoni" <jp.tosoni@...sys.fr>
Cc:	"'Carl-Daniel Hailfinger'" <c-d.hailfinger.devel.2006@....net>,
	"'Robin Getz'" <rgetz@...ckfin.uclinux.org>,
	"'Oleksiy Kebkal'" <kebkal@...il.com>,
	"'Mike Frysinger'" <vapier.adi@...il.com>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>,
	<linux-serial@...r.kernel.org>
Subject: Re: should RTS init in serial core be tied to CRTSCTS

"Tosoni" <jp.tosoni@...sys.fr> writes:

>> OTOH I wonder what does the device in question require WRT the
>> serial port and WRT RTS line in particular.
>> I know there are some half-duplex converters which drive RTS only
>> while sending and which require CTS to send.
>
> As far as I know in the old times this was the *standard* way to use a modem
> (per CCITT V24), and even nowadays many modems can handle this method for
> transmit, to stay compatible with the standard.

I think it wasn't standard for real modems as they were full-duplex
(even these 1200/75 or what was that) but it was for other devices
such as current loops (which were frequently half-duplex).

I've seen such devices quite recently, perhaps ~ 10 years ago.
OTOH I think even "current" PC BIOSes use such signaling.

> Think of radio modems. Some are inherently half duplex.

Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without,
so they don't use such handshaking.

>> They are perhaps a bit broken <snip>
> No, no, they apply an old standard. Probably they are old as well.

I was thinking of a particular piece of hardware and it was definitely
broken a bit. "Selective compliance", maybe.

> It's a pity that Linux (or Unixes) never handled RTS this way.
> I feel that the /proc or sysfs solutions are the best to alter this well
> established default in this driver. It would not break existing installed
> hardware.

/proc is probably no-no.

For such signaling, it would perhaps be better to invent another flag,
similar to CRTSCTS. The driver would, of course, need some real code
for that.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/