linux-kernel - Re: [PATCH] serial: DCC(JTAG) serial and console emulation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Oct 2010 17:32:53 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	Daniel Walker <dwalker@...eaurora.org>
Cc:	linux-kernel@...r.kernel.org,
	"Hyok S. Choi" <hyok.choi@...sung.com>,
	Tony Lindgren <tony@...mide.com>,
	Jeff Ohlstein <johlstei@...cinc.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Ben Dooks <ben-linux@...ff.org>,
	Alan Cox <alan@...ux.intel.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Feng Tang <feng.tang@...el.com>,
	Tobias Klauser <tklauser@...tanz.ch>,
	Jason Wessel <jason.wessel@...driver.com>,
	Philippe Langlais <philippe.langlais@...ricsson.com>
Subject: Re: [PATCH] serial: DCC(JTAG) serial and console emulation support

On Thu, Oct 7, 2010 at 17:17, Daniel Walker wrote:
> 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.

i dont think that's the case.  "any situation" is way too vague and
invites mounds of crap to be included in the kernel which really
should be in userspace.  ive never had a problem with my embedded work
using ttyBF# or ttyBFJC# or ttySS# for the Blackfin serial devices,
nor have i heard customers complain that the file absolutely must be
named "ttyS#".  ive found that simply informing them "to use ttyBF#"
has always been sufficient.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/