linux-kernel - Re: [PATCH 00/20] Implment a tty port structure and supporting logic

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]

Message-Id: <20080520015241.bd66fff0.akpm@linux-foundation.org>
Date:	Tue, 20 May 2008 01:52:41 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/20] Implment a tty port structure and supporting
 logic

On Mon, 19 May 2008 09:50:49 -0700 Greg KH <greg@...ah.com> wrote:

> On Mon, May 19, 2008 at 03:50:07PM +0100, Alan Cox wrote:
> > Right now each tty has its own port level structure which means we can share
> > no code between ports. Introduce a structure and some initial minor helper
> > routines so that we can move towards commonality. In doing this the USB serial
> > code gets a bit of shake up as it kept using port->tty unsafely. Fixing that
> > means changing the API of all the USB serial drivers. On the bright side the
> > API now looks far more like the tty layer API which will become useful later
> > on.
> 
> Very nice.
> 
> If you don't mind, I'll be glad to take this through my tree as you are
> touching the usb-serial drivers so much.  Andrew, any objection to this?

A lot depends on what else Alan is brewing up.  I only have a single
tty-related patch at present (remove-is_tty.patch) and a handful of
possibly-related char driver patches
(proper-extern-for-mwave_s_mdd.patch, if-0-hpet_unregister.patch and
riscom8-remove-redundant-null-pointer-test.patch).

But if a great mountain of tty- and/or char-related patches is
forthcoming, that mountain will probably have a depencency upon your
tree.  And that's OK too, as long as you don't go and bugger up your
tree and get it dropped from linux-next!  Because if that happens I'll
need to temporarily drop all the dependent patches and remember to
restore them, which is always a bit sad.

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