From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 13:12:22 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 7A0F016A4CE for ; Mon, 20 Sep 2004 13:12:22 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF8B43D1F for ; Mon, 20 Sep 2004 13:12:21 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8KD8PlR040788 for arch@FreeBSD.org.checked; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:08:25 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8KD5KqN040639; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:05:20 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414ED61D.5080607@cronyx.ru> Date: Mon, 20 Sep 2004 17:07:41 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <46041.1095665925@critter.freebsd.dk> In-Reply-To: <46041.1095665925@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: Re: [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 13:12:22 -0000 Just an idea: Why not to add some general device enumeration for all devices, especially if devices would behave the same? tty%{global_port} cua%{global_port} rik Poul-Henning Kamp wrote: >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 > > >