mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael H. Warfield" <mhw@wittsend.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: David Weinehall <tao@acc.umu.se>,
	Richard Gooch <rgooch@ras.ucalgary.ca>,
	Ivan Passos <ivan@cyclades.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Serial Driver Name Question (kernels 2.4.x)
Date: Tue, 8 Jan 2002 16:58:51 -0500	[thread overview]
Message-ID: <20020108165851.B26294@alcove.wittsend.com> (raw)
In-Reply-To: <3C33E0D3.B6E932D6@zip.com.au> <3C33BCF3.20BE9E92@cyclades.com> <200201030637.g036bxe03425@vindaloo.ras.ucalgary.ca> <200201062012.g06KCIu16158@vindaloo.ras.ucalgary.ca> <3C38BC19.72ECE86@zip.com.au> <200201070636.g076asR25565@vindaloo.ras.ucalgary.ca> <3C3A7DA7.381D033D@zip.com.au>, <3C3A7DA7.381D033D@zip.com.au>; <20020108071548.J5235@khan.acc.umu.se> <3C3A9048.CB80061A@zip.com.au>
In-Reply-To: <3C3A9048.CB80061A@zip.com.au>

On Mon, Jan 07, 2002 at 10:23:04PM -0800, Andrew Morton wrote:
> David Weinehall wrote:
> > 
> > On Mon, Jan 07, 2002 at 09:03:35PM -0800, Andrew Morton wrote:
> > > [ tty driver name breakage ]
> > >
> > > Richard, can we please get this wrapped up?
> > >
> > > My preferred approach is to change the driver naming scheme
> > > so that we don't have to put printf control-strings everywhere.
> > > We can remove a number of ifdefs that way.
> > 
> > Wouldn't it be cleaner to have:
> > 
> > #ifdef CONFIG_DEVFS_FS
> >         serial_driver.name = "tts/";
> > #else
> >         serial_driver.name = "tts";
> > #endif
> > 
> > and
> > 
> >         sprintf("buf, "%s%d", name, idx + tty->driver.name_base);
> > 
> > respectively?!
> > 

> Well, with the scheme I proposed most drivers won't need the
> ifdef.  It'll just be:

> 	serial_driver.name = "cua";

> With devfs enabled that expands to cua/42.  Without devfs it expands
> to cua42.

	No.

	We've been over this in several lists and there are more
issues here.  The Computone driver is ttyF%d / tts/F%d cuf%d / cua/F%d.
If I understand your convention (and maybe I do not) then the cuf
driver would be what?  Expanded to cuf/42 with devfs and cuf42 without?
That's what it use to be and that created a problem in userland.  The
trouble there is the problem with conventional lock files under
/var/lock which only use the base name of the device name so cua/42
and cuf/42 both have the same lock file of /var/lock/LCK..42 and
would collide.  Yes we could ALSO change ALL the user space applications
using locks, but I just got done changing the Computone driver to conform
to the non-conflicting convention that had been agreed to.  This also
impacts the USB ACM driver and it's devices and lock files.

	Unfortunately, the basenames need to be non-conflicting in flat
name space due the the indeterminant pile of applications which are going
to require non-conflicing lock files under a convention that days back to
before Linux or even Taylor UUCP (HDB UUCP used a similar locking scheme).
That includes pppd, slip, uucp, minicom, cu, ecu, tip, mgetty, etc, etc...

> Seems that some drivers have had their name changed when used under
> devfs (tts/%d versus ttyS%d).  But a lot have not.

	Other drivers which are not under ttyS%d don't make to tts/%d.
As things stand right now, ttyF%d maps to tts/F%d.  It use to be mapped
under ttf/%d but this created a lock file conflict with the tts/%d and
usb/acm/%d devices and had to be changed.

> -
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

  parent reply	other threads:[~2002-01-08 21:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-03  2:07 Ivan Passos
2002-01-03  4:40 ` Andrew Morton
2002-01-03 16:32   ` Ivan Passos
2002-01-03  6:37 ` Richard Gooch
2002-01-03  7:03   ` Andrew Morton
2002-01-06 20:12   ` Richard Gooch
2002-01-06 20:27     ` Richard Gooch
2002-01-06 20:36     ` Alan Cox
2002-01-06 21:05     ` Andrew Morton
2002-01-07  6:36     ` Richard Gooch
2002-01-07  7:20       ` Andrew Morton
2002-01-08  5:03       ` Andrew Morton
2002-01-08  6:15         ` David Weinehall
2002-01-08  6:23           ` Andrew Morton
2002-01-08 18:54             ` Ivan Passos
2002-01-08 21:58             ` Michael H. Warfield [this message]
2002-01-08 22:11               ` Andrew Morton
2002-01-08 23:33                 ` Ivan Passos
2002-01-09 16:36                 ` Richard Gooch
2002-01-10  9:14                   ` Nick Craig-Wood
2002-01-08 18:47         ` Ivan Passos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020108165851.B26294@alcove.wittsend.com \
    --to=mhw@wittsend.com \
    --cc=akpm@zip.com.au \
    --cc=ivan@cyclades.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    --cc=tao@acc.umu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®