From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 07:39:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A562816A4CE for ; Mon, 20 Sep 2004 07:39:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E042643D1F for ; Mon, 20 Sep 2004 07:39:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i8K7cjfI046042 for ; Mon, 20 Sep 2004 09:39:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@FreeBSD.org From: "Poul-Henning Kamp" Date: Mon, 20 Sep 2004 09:38:45 +0200 Message-ID: <46041.1095665925@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [HEADSUP] naming of tty devices. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 07:39:08 -0000 I am convinced that it is important that a serial port behaves predictably no matter what driver implements it, and this is far from the case today. The tty cleanup I'm doing now in preparation for being able to pull all the tty stuff out from under Giant is more or less a matter of getting the drivers to do the same thing by using the same code. There is one outstanding issue though: Device naming The traditional BSD naming scheme as far as I can tell was tty[%{adapter}]%{port} Sun (?) introduced the "cua" devices (Calling Unit Attachment in case you wondered) to allow a modem to be used in both in- and out-going direction at once. Our sio driver, which for many intents and purposes is our reference driver, almost follows this convention: tty[il]d0 + cua[il]a0 = port 0 The 'i' and 'l' reference the "init" and "lock" state respectively. Other drivers have resorted to various variations of this scheme (if they were copy&pasted from sio.c) or rolled their own private naming system. In other words: it's a pretty mess right now. We discussed this naming of tty devices earlier this year (on current) and didn't reach a concensus. This is IMO one of those areas where there is no "perfect" solution given backwards compatibility and therefore the closest to perfect we can get is to define a naming scheme which retains as much compatibility as possible and stick to it. My suggestion is the following: All drivers will offer "tty${something}" devices, and generally ${something} will consist of a letter followed by a number, possibly in base 36 ([0-9a-z]). All drivers which attach to external equipment via a serial connector should also offer "cua${thesamething}". "Embedded" serial ports, pseudo drivers etc, do not have to offer the "cua" if DCD state on open is not an issue. The init and lock devices will be called ${base_device}.[init,lock] and they will possibly be provided by on-demand devices so that they do not clutter up /dev. This results in the following major compatibility issues: sio's cuaa* gets renamed to cuad* sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} ucom's ucom%d gets renamed to ttyU%d ucom gains cuaU%d and .init and .lock devices. uart gains cuau%d and .init and .lock devices. The remaining drivers are pretty obscure and have limited user communities and they will just have to live with things getting straigthend out. I'll admit that this should have been done 10 years ago, but better late than never. Well-argued protests or researched alternatives before friday please. Thanks in advance, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.