linuxconsole-dev

[patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

Hi!

This patch tries to accomplish the same what the previous one did,
basically to clean up the building of the input drivers.

The older one did move all the currently present input drivers in the
kernel, which now only includes joystick and usb ones. With time, the
list will grow (ADB, busmice, PS/2+AT keyb driver, ...). It'd have
been neat to have all that out of drivers/char.

This one moves just the non-USB stuff of the input drivers out of
drivers/usb. That is, the bus-independent userland interface (char
device) modules. It places them in drivers/char. And modifies the
Makefiles and Config.in's accordingly.

Everything after this patch compiles OK. (Current kernel breaks if you
select joysticks and not USB.)

Again, to keep the size down, it's a shell script and a patch. Run the
first, apply the second.

Is this OK? If not, what should I change?

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] The input move patch without moving to input

[Linus T. <tor...@tr...>]

On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> 
> This one moves just the non-USB stuff of the input drivers out of
> drivers/usb. That is, the bus-independent userland interface (char
> device) modules. It places them in drivers/char. And modifies the
> Makefiles and Config.in's accordingly.

I'd actually prefer drivers/input.

The argument I had against drivers/input was not an argument against a new
subdirectory. It was an argument against moving the things like hid.c and
the like to drivers/input, like the email I replied to tried to do.

hid.c is something USB-specific. It had better _not_ be a part of any
"generic input layer". The same is true of usbkbd.c and friends. They are
_usb_ drivers, and shall belong in drivers/usb.

		Linus

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:

> On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > 
> > This one moves just the non-USB stuff of the input drivers out of
> > drivers/usb. That is, the bus-independent userland interface (char
> > device) modules. It places them in drivers/char. And modifies the
> > Makefiles and Config.in's accordingly.
> 
> I'd actually prefer drivers/input.
> 
> The argument I had against drivers/input was not an argument against a new
> subdirectory. It was an argument against moving the things like hid.c and
> the like to drivers/input, like the email I replied to tried to do.
> 
> hid.c is something USB-specific. It had better _not_ be a part of any
> "generic input layer". The same is true of usbkbd.c and friends. They are
> _usb_ drivers, and shall belong in drivers/usb.

Ok. Here is a patch that does that. Any more objections?

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Tue, Aug 22, 2000 at 11:43:26AM +0200, Vojtech Pavlik wrote:
> On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:
> 
> > On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > > 
> > > This one moves just the non-USB stuff of the input drivers out of
> > > drivers/usb. That is, the bus-independent userland interface (char
> > > device) modules. It places them in drivers/char. And modifies the
> > > Makefiles and Config.in's accordingly.
> > 
> > I'd actually prefer drivers/input.
> > 
> > The argument I had against drivers/input was not an argument against a new
> > subdirectory. It was an argument against moving the things like hid.c and
> > the like to drivers/input, like the email I replied to tried to do.
> > 
> > hid.c is something USB-specific. It had better _not_ be a part of any
> > "generic input layer". The same is true of usbkbd.c and friends. They are
> > _usb_ drivers, and shall belong in drivers/usb.
> 
> Ok. Here is a patch that does that. Any more objections?

Replying to myself: This doesn't work. iforce.c (using both serial and
USB interfaces) doesn't get compiled in correctly when only serial
interface is selected.

More work ahead.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

On Tue, Aug 22, 2000 at 12:05:03PM +0200, Vojtech Pavlik wrote:
> On Tue, Aug 22, 2000 at 11:43:26AM +0200, Vojtech Pavlik wrote:
> > On Mon, Aug 21, 2000 at 08:43:37PM -0700, Linus Torvalds wrote:
> > 
> > > On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> > > > 
> > > > This one moves just the non-USB stuff of the input drivers out of
> > > > drivers/usb. That is, the bus-independent userland interface (char
> > > > device) modules. It places them in drivers/char. And modifies the
> > > > Makefiles and Config.in's accordingly.
> > > 
> > > I'd actually prefer drivers/input.
> > > 
> > > The argument I had against drivers/input was not an argument against a new
> > > subdirectory. It was an argument against moving the things like hid.c and
> > > the like to drivers/input, like the email I replied to tried to do.
> > > 
> > > hid.c is something USB-specific. It had better _not_ be a part of any
> > > "generic input layer". The same is true of usbkbd.c and friends. They are
> > > _usb_ drivers, and shall belong in drivers/usb.
> > 
> > Ok. Here is a patch that does that. Any more objections?
> 
> Replying to myself: This doesn't work. iforce.c (using both serial and
> USB interfaces) doesn't get compiled in correctly when only serial
> interface is selected.
> 
> More work ahead.

Done now. Please check this patch if it's OK. It moves iforce.c out of
drivers/usb, but that's necessary. Anyway, iforce.c is more a joystick
driver than an USB driver.

-- 
Vojtech Pavlik
SuSE Labs

Re: [patch] The input move patch without moving to input

[James S. <jsi...@ac...>]

> I'd actually prefer drivers/input.
> 
> The argument I had against drivers/input was not an argument against a new
> subdirectory. It was an argument against moving the things like hid.c and
> the like to drivers/input, like the email I replied to tried to do.
> 
> hid.c is something USB-specific. It had better _not_ be a part of any
> "generic input layer". The same is true of usbkbd.c and friends. They are
> _usb_ drivers, and shall belong in drivers/usb.

Okay. I see your argument for the usb code. The question is where do we
put future non usb input drivers? The different types we can have are
mice, keyboards, and joysticks. Dump them where?  

Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net