From: Greg KH <greg@kroah.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>,
kirk@braille.uwo.ca, linux-kernel@vger.kernel.org,
speakup@braille.uwo.ca, gregkh@suse.de
Subject: Re: 2.6.13-rc2-mm1: some speakup nitpicks
Date: Fri, 8 Jul 2005 20:02:04 -0700 [thread overview]
Message-ID: <20050709030204.GA7974@kroah.com> (raw)
In-Reply-To: <20050709020717.GQ3671@stusta.de>
On Sat, Jul 09, 2005 at 04:07:18AM +0200, Adrian Bunk wrote:
> On Thu, Jul 07, 2005 at 04:00:37AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.13-rc1-mm1:
> >...
> > +gregkh-driver-speakup-docs.patch
> > +gregkh-driver-speakup-core.patch
> >
> > driver-core updates
> >...
>
> These aren't driver-core updates, these are new drivers.
Yeah, sorry, I put them in my tree, in order for me to work on them.
> It seems I missed when this was sent for review to linus-kernel.
Heh, it's no where ready for such review, it needs a lot of cleanup. I
did a lot of it about 12 months ago, but lost it somehow, don't want to
do that again...
I would not recommend reading the code just yet, unless you want to feel
ill...
> Some random nitpicks:
>
> - SPEAKUP_DEFAULT shouldn't be asked if SPEAKUP=n
> - "make namespacecheck" shows tons of needlessly global code
> - the static variable special_handler is EXPORT_SYMBOL'ed
> - #define MIN should be removed
> - the file cvsversion.h only for keeping a CVS date is a bit
> overkill
> - spk_con_module.h is not exactly how we use header files in the kernel
> - many of the #ifdef MODULE's point to things that could be done better
> (especially the #include "mod_code.c"'s)
> - the things in synthlist.h could be done less ugly
> - speakupconf is a userspace script that belongs under Documentation/
> - dtload.c is not kernel code, and should therefore not be in that
> directory
> - the code should follow Documentation/CodingStyle better
> (no spaces between the braces and function arguments)
> - building speakup_keyhelp.c modular even in a kernel that doesn't
> support modules is silly
> - #include <linux/...> belongs before #include <asm/...>
Yes, that's just the start of what needs to be done. But I like it in
the -mm tree for now to at least give it wider testing to users who rely
on this hardware in order to have access to their machines. I'll be
slowly working on it over the next month or so to fix these issues and
the placement of where it hooks into the main kernel. Then I will
submit the driver for review by all of lkml. I will not send it to
Linus until everyone agrees that it is acceptable.
thanks,
greg k-h
next prev parent reply other threads:[~2005-07-09 3:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-07 11:00 2.6.13-rc2-mm1 Andrew Morton
2005-07-07 11:27 ` 2.6.13-rc2-mm1 Miklos Szeredi
2005-07-07 11:34 ` 2.6.13-rc2-mm1 Andrew Morton
2005-07-07 11:44 ` 2.6.13-rc2-mm1 Miklos Szeredi
2005-07-07 11:32 ` 2.6.13-rc2-mm1 Brice Goglin
2005-07-07 11:42 ` 2.6.13-rc2-mm1 Andrew Morton
2005-07-07 11:44 ` 2.6.13-rc2-mm1 Brice Goglin
2005-07-07 12:46 ` 2.6.13-rc2-mm1 Michael Krufky
2005-07-07 14:19 ` 2.6.13-rc2-mm1 Robert Love
2005-07-07 16:14 ` 2.6.13-rc2-mm1 Roland Dreier
2005-07-09 2:07 ` 2.6.13-rc2-mm1: some speakup nitpicks Adrian Bunk
2005-07-09 3:02 ` Greg KH [this message]
2005-07-09 13:16 ` Alexey Dobriyan
2005-07-11 16:29 ` 2.6.13-rc2-mm1 - unknown symbol: is_broadcast_ether_addr Damir Perisa
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=20050709030204.GA7974@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=gregkh@suse.de \
--cc=kirk@braille.uwo.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=speakup@braille.uwo.ca \
/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