Re: [HEADSUP] naming of tty devices.

From: Roman Kurakin (rik_at_cronyx.ru)
Date: 09/20/04

  • Next message: Poul-Henning Kamp: "Re: [HEADSUP] naming of tty devices."
    Date: Mon, 20 Sep 2004 17:07:41 +0400
    To: Poul-Henning Kamp <phk@phk.freebsd.dk>
    
    

    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
    >
    >
    >

    _______________________________________________
    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: Poul-Henning Kamp: "Re: [HEADSUP] naming of tty devices."

    Relevant Pages

    • [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 ... areas where there is no "perfect" solution given backwards compatibility ...
      (freebsd-arch)
    • 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: 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: Be a JLEDI or Cause Road Rage
      ... the matter at hand, you see. ... If it did, that was the MFFY's decision and his responsibility, ... Please explain how someone's tailgating forces another driver ... to attempt an unsafe lane change. ...
      (rec.autos.driving)