[HEADSUP] naming of tty devices.

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 09/20/04

  • Next message: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices." 
    To: arch@FreeBSD.org
Date: Mon, 20 Sep 2004 09:38:45 +0200

    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.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices."

    Relevant Pages

    • Re: Sometimes its okay to make someone brake when moving into passing lane
      ... not naming names, because I really don't remember who said it) said what ... I interpreted as you should never change lanes to the left and cause ... Provided that driver is behaving properly. ... to brake if they maintained their cruising speed. ...
      (rec.autos.driving)
    • Re: [HEADSUP] naming of tty devices.
      ... >is more or less a matter of getting the drivers to do the same thing ... >The traditional BSD naming scheme as far as I can tell was ... >Our sio driver, which for many intents and purposes is our reference ...
      (freebsd-arch)
    • Re: If you are accused of exceeding the speed limit
      ... offence to which this section applies-. ... reasonable diligence have ascertained who the driver of the vehicle ... answer for naming the wrong person. ...
      (uk.legal)
    • Re: Service Enum params
      ... > particularly since you're naming your device with a number. ... A device interface registered by the driver will have a constant name (some ... >When the application tries to install another instance of bus driver, ...
      (microsoft.public.development.device.drivers)
    • Re: various power management related issues
      ... Details on the compatibility requirements and available test for each ... > My question is if this can be OS problem or driver problem? ... > doesnt work anymore after coming back from hibernate, ... > the modem has its own power cable so its always turned on even if the box is ...
      (microsoft.public.development.device.drivers)