From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756548Ab0JGVSV (ORCPT ); Thu, 7 Oct 2010 17:18:21 -0400 Received: from wolverine02.qualcomm.com ([199.106.114.251]:55003 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756515Ab0JGVSU (ORCPT ); Thu, 7 Oct 2010 17:18:20 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6129"; a="56990945" Subject: Re: [PATCH] serial: DCC(JTAG) serial and console emulation support From: Daniel Walker To: Mike Frysinger Cc: linux-kernel@vger.kernel.org, "Hyok S. Choi" , Tony Lindgren , Jeff Ohlstein , Greg Kroah-Hartman , Ben Dooks , Alan Cox , Kukjin Kim , Feng Tang , Tobias Klauser , Jason Wessel , Philippe Langlais In-Reply-To: References: <1286476616-3373-1-git-send-email-dwalker@codeaurora.org> <1286480364.23836.17.camel@c-dwalke-linux.qualcomm.com> <1286481532.23836.27.camel@c-dwalke-linux.qualcomm.com> <1286482013.23836.29.camel@c-dwalke-linux.qualcomm.com> <1286485186.23836.56.camel@c-dwalke-linux.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Oct 2010 14:17:54 -0700 Message-ID: <1286486274.23836.62.camel@c-dwalke-linux.qualcomm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2010-10-07 at 17:05 -0400, Mike Frysinger wrote: > On Thu, Oct 7, 2010 at 16:59, Daniel Walker wrote: > > On Thu, 2010-10-07 at 16:47 -0400, Mike Frysinger wrote: > >> On Thu, Oct 7, 2010 at 16:06, Daniel Walker wrote: > >> > On Thu, 2010-10-07 at 16:02 -0400, Mike Frysinger wrote: > >> >> how is that any different from: > >> >> ln -s ttyJ0 /dev/ttyS0 > >> > > >> > It has the same major and minors as ttyS* does. So you don't have to run > >> > anything on the target. > >> > >> i dont see how those things are related. the major/minor are > >> irrelevant, unless you've already hard coded these in some app that > >> creates device nodes manually (instead of mdev/udev), but even then > >> that's something that "needs to be run on the target". and both > >> already have config support to transparently do something like > >> "symlink ttyS# to XXX" as XXX is created. > > > > Something does ultimately run on all targets, the issues is does the > > person debugging have the ability to change it .. It's not always the > > case that they can change it. The userspace may not have udev at all. > > The userspace may consist of a single binary .. I'm not making any > > assumptions about the userspace here, it can be anything. > > then there is already a static rootfs with pre-populated /dev which > would be fixed, or the single binary fixed. if the options are "my > system works" or "my system doesnt work", i cant imagine people would > continue to attempt to use "/dev/ttyS#" if it didnt exist or didnt > work. Ideally you would want this driver to work in any situation .. If it's setup to use ttyS0 for debugging, even if it doesn't exist, then this driver would be able to stand in for that interface. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.