lkml.org 
[lkml]   [2002]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH/RFC 2.4.19-rc1] Fix dependancies on keybdev.o
Date
On Thu, 27 Jun 2002 00:46, Tom Rini wrote:
> On Wed, Jun 26, 2002 at 12:36:24PM +1000, Brad Hards wrote:
> > 2. Move keyboard handling code to input subsystem
>
> I think that will work out the best. How's the attached look? It moves
> drivers/input/Config.in inside of drivers/char/Config.in and then fixes
> arches which had both. (Lightly tested from xconfig[1] for all arches
> which got changed).
I'm opposed to further junk going into drivers/char. It is already an
incomprehensible mess of unrelated code.

> > 3. Do wholesale backport of input subsystem from 2.5
>
> Not really an option (and 2.5 has this problem anyhow) since it's so
> invasive, once it's done.
Concur with the invasiveness angle.

Actually, I've got another idea, based on some stuff that I've been working on
for the ACPI "its not just power management" issue.

If you need to set something in drivers/input (per your original patch) that
depends on things that are set in drivers/char (or drivers/usb, anything that
comes later), then split the Config.in into two sections. One section
contains the normal Config.in user-selectable options, and a second
drivers/input/Config-post.in, that is sourced in at the end of
arch/foo/config.in and contains only automated Config.in dependancies (ie
define_bool) but no user selectable options.

Does this make sense? If not, I'll try for a patch that shows it later this
morning.

Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.066 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site