All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg KH <gregkh@suse.de>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	Jiri Slaby <jslaby@suse.cz>,
	alan@linux.intel.com, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jiri Slaby <jirislaby@gmail.com>
Subject: Re: [PATCH] serial: relocate remaining serial drivers from tty/ to tty/serial/
Date: Wed, 4 Jan 2012 23:27:33 +0000	[thread overview]
Message-ID: <201201042327.33739.arnd@arndb.de> (raw)
In-Reply-To: <20120104220332.GA22985@suse.de>

On Wednesday 04 January 2012, Greg KH wrote:
> > 
> > My thinking was that having a drivers/tty/serial dir and then
> > not having all the serial drivers in that dir violated the
> > principle of least surprise.  Is there a reason why the dir should
> > be the exclusive domain of drivers with a dependency on SERIAL_CORE?
> 
> Because that is what the directory is for?  :)
> 
> We have other "serial" like drivers all over the kernel, this was for
> the SERIAL_CORE drivers only at the moment.

My initial plan when moving some files to drivers/tty was to have a separate
directory for the non-SERIAL_CORE serial drivers next to drivers/tty/serial.

I would still prefer this solution, but I think we never agreed on a good
name for that directory. IIRC, I had suggested drivers/tty/legacy believing
that SERIAL_CORE was the modern way to implement a serial driver, but that
turned out not to be true and at lease one of these (bfin_jtag) is not
a legacy driver in practice.

Maybe drivers/tty/hw? I think that one has been suggested before, too.
I don't remember any argument against it and I think it would be nice
to separate the core implementation from actual device drivers.

	Arnd

  reply	other threads:[~2012-01-04 23:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04 20:01 [PATCH] serial: relocate remaining serial drivers from tty/ to tty/serial/ Paul Gortmaker
2012-01-04 20:34 ` Jiri Slaby
2012-01-04 20:51   ` Greg KH
2012-01-04 21:07     ` Paul Gortmaker
2012-01-04 21:07       ` Paul Gortmaker
2012-01-04 22:03       ` Greg KH
2012-01-04 23:27         ` Arnd Bergmann [this message]
2012-01-05  5:42           ` Sam Ravnborg
2012-01-05 12:45             ` Alan Cox
2012-01-05 23:21               ` Paul Gortmaker
2012-01-05 23:21                 ` Paul Gortmaker
2012-01-06 13:42                 ` Greg KH
2012-02-08 10:30                 ` Jiri Slaby
2012-02-08 10:32                   ` Jiri Slaby
2012-02-08 13:58                     ` Paul Gortmaker
2012-02-08 13:58                       ` Paul Gortmaker
2012-02-08 14:12                     ` Paul Gortmaker
2012-02-08 14:12                       ` Paul Gortmaker
2012-01-04 22:01 ` Alan Cox
2012-01-04 22:43   ` Paul Gortmaker
2012-01-04 22:43     ` Paul Gortmaker

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=201201042327.33739.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alan@linux.intel.com \
    --cc=gregkh@suse.de \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.