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:	Fri, 08 Oct 2010 09:11:13 -0700
From:	Daniel Walker <dwalker@...eaurora.org>
To:	Greg KH <gregkh@...e.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Mike Frysinger <vapier@...too.org>,
	linux-kernel@...r.kernel.org,
	"Hyok S. Choi" <hyok.choi@...sung.com>,
	Tony Lindgren <tony@...mide.com>,
	Jeff Ohlstein <johlstei@...cinc.com>,
	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 Fri, 2010-10-08 at 08:40 -0700, Greg KH wrote:
> On Fri, Oct 08, 2010 at 08:23:54AM -0700, Daniel Walker wrote:
> > > And if your hypothetical user isn't able to do this then maybe instead of
> > > trying to screw up the kernel for everyone they should ask an
> > > undergraduate student who is smart enough to help them.
> > 
> > I don't think the kernel is going to implode if we allow an optional
> > ttyS override for debugging purposes.. I just don't see that "screwing"
> > up the kernel. I can even embedded that inside the C file, and not make
> > it a Kconfig option ..
> 
> I admire your persistence, but perhaps you should take a step back and
> look at the history here.  You just want this override.  Then someone
> else does, and then, someone else.  Eventually we are all overridden.
> 
> Remember, you aren't unique here, as much as you might feel like you are
> :)

It's not that _I_ want it .. If you look at the code it's not that huge
a part of the source .. It's got it's own ttyJ already, and it's
ifdefe'd. It would be pretty easy to remove it. The other thing is that
it's not something I use, so for me it's kind of take it or leave it.

So why am I arguing to keep it? Well the original author added it for a
purpose, which I can't assume was useless .. I can also imagine
situations when it would be helpful to do this.

To me it's more a question of if the override is useful or not .. If
it's useful then it's just about organizing the code so the kernel
doesn't melt down if we allow it.

Thinking about it overrides are actually allowed right now, it's just
that you have to mod the source some to do it.

> Please listen to what Alan and Mike are saying, experience matters, and
> they are trying to impart it to you, despite your most fervent attempts
> to avoid it.

The whole "fervent" thing is kind of funny to me.. I'm just persistent,
that's what it's comes down to. Like I said above I'm not "in love" with
this feature. I am actually taking Mike and Alan's advice by the way, so
it's not like I'm not listening (or reading in this case)..

Daniel

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


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ