mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@codeaurora.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org,
	"Hyok S. Choi" <hyok.choi@samsung.com>,
	Tony Lindgren <tony@atomide.com>,
	Jeff Ohlstein <johlstei@quicinc.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Ben Dooks <ben-linux@fluff.org>, Alan Cox <alan@linux.intel.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Mike Frysinger <vapier@gentoo.org>,
	Feng Tang <feng.tang@intel.com>,
	Tobias Klauser <tklauser@distanz.ch>,
	Jason Wessel <jason.wessel@windriver.com>,
	Philippe Langlais <philippe.langlais@stericsson.com>
Subject: Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
Date: Thu, 07 Oct 2010 14:41:58 -0700	[thread overview]
Message-ID: <1286487718.23836.94.camel@c-dwalke-linux.qualcomm.com> (raw)
In-Reply-To: <20101007223819.46246716@lxorguk.ukuu.org.uk>

On Thu, 2010-10-07 at 22:38 +0100, Alan Cox wrote:
> > Your making too many assumptions .. You might be able to modify the
> > kernel, and not the userspace. So you couldn't tweak the device
> > creation .. It's much easier in the server world ..
> 
> Spare me the embedded is different lecture. It's not. In fact it's
> usually easier because the environment you are testing is usually
> standalone, doesn't cause a million dollar an hour downtime if you get it
> wrong and was designed for debug/test so actually has a jtag port.

fair enough, it's hard for both of us.

> If you can modify the file system you can make /dev/ttyS0 the major/minor
> of the jtag port.
> 
> If you can load anything in front of the userspace you can rename the
> device/move it
> 
> So I find your example case fictional. In fact the only time I can see
> you having a box so tightly locked up you can only tweak the kernel is
> jailbreaking it, in which case you are such a fringe usage case and
> technically competent that you can just do custom patches as you'll be
> doing anyway for other bits.

There's lots of other situations that can come up. You can't in anyway
say that there is some certain set of situations where you'll always
have X, Y, and Z.. There have been enough strange situations that I
don't think it's right for you or me to assume we just know what they
all are.

> > > We've said no over a period of about ten years to a lot of attempts to
> > > just borrow the ttyS0 range. If we'd said yes it would have been a
> > > complete mess by now.
> > > 
> > > So the answer is no.
> > 
> > Nothing can be unilateral, there's always room for exceptions. You
> > should say something more like "it's possible, but unlikely".
> 
> This argument gets regurgitated every so often and nobody has yet
> provided a plausable reason to make a nasty mess.

There's plenty of nasty messes in the kernel, "they" must have had some
justification ..

> Either way I would suggest the path forward is
> 
> - Look at the blackfin jtag using tty_port alone and see if it looks
>   cleaner

Yeah ..

> - Fix the bugs noted

Check,

> - Submit a driver that uses the existing allocated jtag major/minor only

The driver does this already. It uses ttyJ* by default, and ttyS is an
option ..

> and then have a debate about ttyS0 hackery separately.

Fine with me..

-- 

Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


  reply	other threads:[~2010-10-07 21:42 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07 18:36 Daniel Walker
2010-10-07 19:25 ` Mike Frysinger
2010-10-07 19:39   ` Daniel Walker
2010-10-07 19:48     ` Mike Frysinger
2010-10-07 19:58       ` Daniel Walker
2010-10-07 20:02         ` Mike Frysinger
2010-10-07 20:06           ` Daniel Walker
2010-10-07 20:47             ` Mike Frysinger
2010-10-07 20:59               ` Daniel Walker
2010-10-07 21:05                 ` Mike Frysinger
2010-10-07 21:17                   ` Daniel Walker
2010-10-07 21:32                     ` Mike Frysinger
2010-10-07 21:50                       ` Daniel Walker
2010-10-07 20:52   ` Alan Cox
2010-10-07 20:37     ` Daniel Walker
2010-10-07 21:08       ` Alan Cox
2010-10-07 20:50 ` Alan Cox
2010-10-07 20:36   ` Daniel Walker
2010-10-07 21:05     ` Alan Cox
2010-10-07 20:51       ` Daniel Walker
2010-10-07 21:03         ` Mike Frysinger
2010-10-07 21:14           ` Daniel Walker
2010-10-08  8:13             ` Alan Cox
2010-10-08 15:23               ` Daniel Walker
2010-10-08 15:40                 ` Greg KH
2010-10-08 16:11                   ` Daniel Walker
2010-10-08 16:56                 ` Alan Cox
2010-10-08 16:45                   ` Daniel Walker
2010-10-08 18:38                     ` Mike Frysinger
2010-10-08 19:01                       ` Daniel Walker
2010-10-08 19:20                         ` Mike Frysinger
2010-10-08 19:50                           ` Daniel Walker
2010-10-08 22:02                             ` Mike Frysinger
2010-10-08 22:22                               ` Daniel Walker
2010-10-09  5:38                                 ` Mike Frysinger
2010-10-07 21:15         ` Greg KH
2010-10-07 21:47           ` Daniel Walker
2010-10-07 21:52             ` Greg KH
2010-10-07 22:11               ` Daniel Walker
2010-10-08  2:04                 ` Mike Frysinger
2010-10-07 21:38         ` Alan Cox
2010-10-07 21:41           ` Daniel Walker [this message]
2010-10-08  8:18             ` Alan Cox
2010-10-08 15:16               ` Daniel Walker
2010-10-08  4:59 Daniel Walker
2010-10-08  6:05 ` Mike Frysinger
2010-10-08 19:34 matthieu castet
2010-10-08 19:52 ` Daniel Walker
2010-10-08 19:55 ` Daniel Walker
2010-10-08 20:40   ` matthieu castet

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=1286487718.23836.94.camel@c-dwalke-linux.qualcomm.com \
    --to=dwalker@codeaurora.org \
    --cc=alan@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ben-linux@fluff.org \
    --cc=feng.tang@intel.com \
    --cc=gregkh@suse.de \
    --cc=hyok.choi@samsung.com \
    --cc=jason.wessel@windriver.com \
    --cc=johlstei@quicinc.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=philippe.langlais@stericsson.com \
    --cc=tklauser@distanz.ch \
    --cc=tony@atomide.com \
    --cc=vapier@gentoo.org \
    /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

Powered by JetHome