Patches for 2.4.0-test7

Patches for 2.4.0-test7

[Martin Costabel]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

Hi,

here are some patches that are necessary for 2.4.0-test7 (bitkeeper as
well as pmac-devel) to compile and run.

Some of them have been sent to the list (even repeatedly) before (by me
and
others). Now that the gun smoke over the drivers/input battlefield has
lifted, I dare resubmit them and hope they won't continue to be ignored.

- The patch for arch/ppc/kernel/ppc_ksyms.c is necessary if you want to
compile rtc as a module. If you don't want it as a module, you don't
need to EXPORT these variables at all.

- The patch for include/asm-ppc/mman.h is necessary so that the loop
device ("mount -o loop") works. I suppose the values for these MCL_*
variables have been chosen by analogy to some other architectures, but
they are already defined by glibc in /usr/include/bits/mman.h, so you
can't take arbitrary values.

- The patch for drivers/macintosh/Makefile is necessary for successful
compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
which is possible with the latest version of the new input layer. (Not
that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
that's another story).

I have 3 other pet peeves that I would like to recall:

- I think the new input layer with CONFIG_INPUT_ADBHID=y and
CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
that they differ from what all other kernels from the oldest times up to
linux-pmac-devel before yesterday were giving. The tables,
mac_keycodes[]
in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c, are probably correct. But then
adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
if it detects an ISO ADB keyboard. IMHO the swapping should occur for
USB
keyboards and not for ADB keyboards. I had some discussion with Franz
which was not conclusive.

My question is: Are these 2 keys giving correct results if one has
either dev.mac_hid.keyboard_sends_linux_keycodes=1 or an ISO USB
keyboard?

- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
variable, therefore stopping Mozilla from running. This is so weird (but
consistent since several months) that I have not the faintest idea where
it could come from. It is a feature of linux-pmac-devel, not present in
linux-bk-devel.

- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
from working. I have no idea what's wrong, but it would be nice to have
a working strace again.

--
Martin

[-- Attachment #2: ppc_ksyms.patch --]
[-- Type: text/plain, Size: 341 bytes --]

--- arch/ppc/kernel/ppc_ksyms.c.ori	Tue Aug 22 01:45:16 2000
+++ arch/ppc/kernel/ppc_ksyms.c	Sat Aug 26 11:37:28 2000
@@ -259,7 +259,7 @@
 EXPORT_SYMBOL(pmac_xpram_read);
 EXPORT_SYMBOL(pmac_xpram_write);
 #endif /* CONFIG_NVRAM */
-#ifdef CONFIG_PPC_RTC
+#ifdef CONFIG_PPC_RTC_MODULE
 EXPORT_SYMBOL(mktime);
 EXPORT_SYMBOL(to_tm);
 #endif


[-- Attachment #3: mman.h.patch --]
[-- Type: text/plain, Size: 578 bytes --]

--- include/asm-ppc/mman.h.ori	Sat Mar 25 06:50:09 2000
+++ include/asm-ppc/mman.h	Thu Aug 17 17:18:47 2000
@@ -22,8 +22,8 @@
 #define MS_INVALIDATE	2		/* invalidate the caches */
 #define MS_SYNC		4		/* synchronous memory sync */

-#define MCL_CURRENT	1		/* lock all current mappings */
-#define MCL_FUTURE	2		/* lock all future mappings */
+#define MCL_CURRENT	0x2000		/* lock all current mappings */
+#define MCL_FUTURE	0x4000		/* lock all future mappings */

 #define MADV_NORMAL	0x0		/* default page-in behavior */
 #define MADV_RANDOM	0x1		/* page-in minimum required */


[-- Attachment #4: macintosh.patch --]
[-- Type: text/plain, Size: 367 bytes --]

--- drivers/macintosh/Makefile~	Fri Aug 25 08:52:03 2000
+++ drivers/macintosh/Makefile	Sat Aug 26 12:59:40 2000
@@ -51,6 +51,7 @@

 obj-$(CONFIG_ADB)		+= adb.o
 obj-$(CONFIG_ADB_KEYBOARD)	+= mac_keyb.o
+obj-$(CONFIG_ADBMOUSE)		+= mac_keyb.o
 obj-$(CONFIG_ADB_MACII)		+= via-macii.o
 obj-$(CONFIG_ADB_MACIISI)	+= via-maciisi.o
 obj-$(CONFIG_ADB_CUDA)		+= via-cuda.o

Re: Patches for 2.4.0-test7

[Benjamin Herrenschmidt]

>- The patch for arch/ppc/kernel/ppc_ksyms.c is necessary if you want to
>compile rtc as a module. If you don't want it as a module, you don't
>need to EXPORT these variables at all.

I'll merge that one.

>- The patch for include/asm-ppc/mman.h is necessary so that the loop
>device ("mount -o loop") works. I suppose the values for these MCL_*
>variables have been chosen by analogy to some other architectures, but
>they are already defined by glibc in /usr/include/bits/mman.h, so you
>can't take arbitrary values.

This one is waiting for Cort or Paul ack.

>- The patch for drivers/macintosh/Makefile is necessary for successful
>compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
>which is possible with the latest version of the new input layer. (Not
>that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
>that's another story).

AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
the current bk tree. I'm also doing additional config fixes, so that ADB-
less pmacs can remove all the ADB stuffs and keep the PMU for example.
CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...

I though about making adbhid.c call the appropriate hooks in adbmouse to
make it work. After more thinking, I beleive it would be only bloat. Use
either the old drivers with your old userland setup, or the new drivers
with a new userland setup, with the mice all coming from /dev/input/mice.

>I have 3 other pet peeves that I would like to recall:
>
>- I think the new input layer with CONFIG_INPUT_ADBHID=y and
>CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
>wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
>that they differ from what all other kernels from the oldest times up to
>linux-pmac-devel before yesterday were giving. The tables,
>mac_keycodes[]
>in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
>drivers/macintosh/adbhid.c, are probably correct. But then
>adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
>if it detects an ISO ADB keyboard. IMHO the swapping should occur for
>USB
>keyboards and not for ADB keyboards. I had some discussion with Franz
>which was not conclusive.

They need to be fixed in the userland keymaps. We had it wrong at first.
Some keyboards have those actually swapped, and Franz cold should be ok
(it was tested with all sorts of keyboards, AFAIK, and now, a fixed
keymap should give good results everywhere).

>- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
>variable, therefore stopping Mozilla from running. This is so weird (but
>consistent since several months) that I have not the faintest idea where
>it could come from. It is a feature of linux-pmac-devel, not present in
>linux-bk-devel.

The two kernels are now in sync. Do you still have the problem ?

>- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
>from working. I have no idea what's wrong, but it would be nice to have
>a working strace again.

AFAIK, Paul pushed a fix for that in bk a couple of days ago.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Martin Costabel]

Benjamin Herrenschmidt wrote:

> >- The patch for drivers/macintosh/Makefile is necessary for successful
> >compilation if you have CONFIG_ADBMOUSE, but not CONFIG_ADB_KEYBOARD,
> >which is possible with the latest version of the new input layer. (Not
> >that the adbmouse works for me if I choose CONFIG_INPUT_ADBHID=y, but
> >that's another story).
>
> AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
> the current bk tree. I'm also doing additional config fixes, so that ADB-
> less pmacs can remove all the ADB stuffs and keep the PMU for example.
> CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...

Someone recently wrote that one could have both /dev/adbmouse and
/dev/input/mice working at the same time, so I tried this, too. And I
*could* select CONFIG_ADBMOUSE without CONFIG_ADB_KEYBOARD, only it
didn't compile due to undefined variables. My patch fixes these, but
indeed it is probably better to change the config.in files to forbid
this choice.

> >I have 3 other pet peeves that I would like to recall:
> >
> >- I think the new input layer with CONFIG_INPUT_ADBHID=y and
> >CONFIG_MAC_ADBKEYCODES=y on an ISO (=European) ADB keyboard gives the
> >wrong keycodes for the 2 keys with codes 10 and 50. Wrong in the sense
> >that they differ from what all other kernels from the oldest times up to
> >linux-pmac-devel before yesterday were giving. The tables,
> >mac_keycodes[]
> >in drivers/input/keybdev.c and adb_to_linux_keycodes[] in
> >drivers/macintosh/adbhid.c, are probably correct. But then
> >adbhid_input_register() in drivers/macintosh/adbhid.c swaps the 2 keys
> >if it detects an ISO ADB keyboard. IMHO the swapping should occur for
> >USB
> >keyboards and not for ADB keyboards. I had some discussion with Franz
> >which was not conclusive.
>
> They need to be fixed in the userland keymaps. We had it wrong at first.
> Some keyboards have those actually swapped, and Franz cold should be ok
> (it was tested with all sorts of keyboards, AFAIK, and now, a fixed
> keymap should give good results everywhere).

I wouldn't mind changing the keymaps, but I really would like to use the
same keymaps for 2.2.x kernels, for 2.4.0-test kernels with
CONFIG_ADB_KEYBOARD and with CONFIG_INPUT_ADBHID.

> >- Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
> >variable, therefore stopping Mozilla from running. This is so weird (but
> >consistent since several months) that I have not the faintest idea where
> >it could come from. It is a feature of linux-pmac-devel, not present in
> >linux-bk-devel.
>
> The two kernels are now in sync. Do you still have the problem ?

Yes, it is still there, I just verified. There must be some difference
between Paul's kernel and the bitkeeper tree that causes this. Here is
another strange observation:

I type "printenv", and LD_LIBARY_PATH is listed with the other env
variables (with "env", it does not get listed). Now I use the newly
recovered strace (see below) to try to understand what printenv does
differently from env. Well, "strace printenv" does not show
LD_LIBARY_PATH any more!

> >- Finally: The ptrace code in 2.4.0-testX has a bug that prevents strace
> >from working. I have no idea what's wrong, but it would be nice to have
> >a working strace again.
>
> AFAIK, Paul pushed a fix for that in bk a couple of days ago.

Yes, sorry, you are right. strace works again. I had tried it with a
kernel from 2 days ago. I see now Paul's yesterday's 1-line fix in
arch/ppc/kernel/entry.S. Very good!
>
> Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Benjamin Herrenschmidt]

>
>I wouldn't mind changing the keymaps, but I really would like to use the
>same keymaps for 2.2.x kernels, for 2.4.0-test kernels with
>CONFIG_ADB_KEYBOARD and with CONFIG_INPUT_ADBHID.

Well, my kernel for now are the only 2.2 to contain the new stuff and
support for linux keycodes. It's currently a different implementation
than the one in 2.4. I beleive that at a given point in the future, we'll
inherit from the 2.4 version in our 2.2 kernels via the USB backport.

>Yes, it is still there, I just verified. There must be some difference
>between Paul's kernel and the bitkeeper tree that causes this. Here is
>another strange observation:
>
>I type "printenv", and LD_LIBARY_PATH is listed with the other env
>variables (with "env", it does not get listed). Now I use the newly
>recovered strace (see below) to try to understand what printenv does
>differently from env. Well, "strace printenv" does not show
>LD_LIBARY_PATH any more!

Ok, I'll look if I see something, but we are in parts of the kernel here
that I don't know very well. Paul, any idea ?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Paul Mackerras]

Martin Costabel writes:

> - Paul's pmac-devel kernel still eats the LD_LIBRARY_PATH environment
> variable, therefore stopping Mozilla from running. This is so weird (but
> consistent since several months) that I have not the faintest idea where
> it could come from. It is a feature of linux-pmac-devel, not present in
> linux-bk-devel.

Found this one. :-)  Thanks for alerting me to it.  This was because I
have some mods in my tree to add extra aux table entries for the ppc
cache line size.  I was using the numbers assigned in the Sys V ABI
but these conflict with numbers assigned to other things by linux.
The end result was that ld.so always thought it was loading a setuid
program and therefore disabled LD_LIBRARY_PATH.  It's now fixed in my
rsync tree.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Benjamin Herrenschmidt]

>Found this one. :-)  Thanks for alerting me to it.  This was because I
>have some mods in my tree to add extra aux table entries for the ppc
>cache line size.  I was using the numbers assigned in the Sys V ABI
>but these conflict with numbers assigned to other things by linux.
>The end result was that ld.so always thought it was loading a setuid
>program and therefore disabled LD_LIBRARY_PATH.  It's now fixed in my
>rsync tree.

BTW. The cset I sent you contains code from Dan Malek that implements an
elegant solution to the CPU detection stuff by emulating the "mfspr"
instruction when issued from userland. We can also (not done yet)
masquerade the CPU (by letting it think it's a G3 and not a G4 when
altivec is not enabled in the kernel for example).


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Michael Schmitz]

> > AFAIK, CONFIG_ADBMOUSE cannot be selected without CONFIG_ADB_KEYBOARD in
> > the current bk tree. I'm also doing additional config fixes, so that ADB-
> > less pmacs can remove all the ADB stuffs and keep the PMU for example.
> > CONFIG_ADB_KEYBOARD is not displayed when CONFIG_INPUT_ADBHID is, etc...
>
> Someone recently wrote that one could have both /dev/adbmouse and
> /dev/input/mice working at the same time, so I tried this, too. And I
> *could* select CONFIG_ADBMOUSE without CONFIG_ADB_KEYBOARD, only it
> didn't compile due to undefined variables. My patch fixes these, but
> indeed it is probably better to change the config.in files to forbid
> this choice.

That would have been me - I still claim that keeping adbmouse working for
backwards compatibility would be a good thing, but my word doesn't carry
much weight.

The adbmouse driver only relies on the keyboard driver for mouse button
emulation. At least in 2.2.17, it won't interfere with the new input code,
I haven't tried 2.4.0 yet.

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Paul Mackerras]

Michael Schmitz writes:

> That would have been me - I still claim that keeping adbmouse working for
> backwards compatibility would be a good thing, but my word doesn't carry
> much weight.
>
> The adbmouse driver only relies on the keyboard driver for mouse button
> emulation. At least in 2.2.17, it won't interfere with the new input code,
> I haven't tried 2.4.0 yet.

The way it is at the moment in the linuxppc_2_3 bk tree and in my
rsync tree, you have 3 choices:

1. use mac_keyb.c/adbmouse.c and don't have the input layer at all
2. use the input layer for USB devices and mac_keyb.c/adbmouse.c for
   ADB keyboard and mouse
3. use the input layer for both USB and ADB devices.

The adbmouse driver references some external variables which are
declared in mac_keyb.c.  If there is really a need to have adbmouse.c
in the system without mac_keyb.c, we can probably work out a way to
allow that, but I don't see the need.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Martin Costabel]

Paul Mackerras wrote:
>
> Michael Schmitz writes:
>
> > That would have been me - I still claim that keeping adbmouse working for
> > backwards compatibility would be a good thing, but my word doesn't carry
> > much weight.

> The way it is at the moment in the linuxppc_2_3 bk tree and in my
> rsync tree, you have 3 choices:
>
> 1. use mac_keyb.c/adbmouse.c and don't have the input layer at all
> 2. use the input layer for USB devices and mac_keyb.c/adbmouse.c for
>    ADB keyboard and mouse
> 3. use the input layer for both USB and ADB devices.
>
> The adbmouse driver references some external variables which are
> declared in mac_keyb.c.  If there is really a need to have adbmouse.c
> in the system without mac_keyb.c, we can probably work out a way to
> allow that, but I don't see the need.

While I fully agree with Paul that it is better to impose clear choices
so you need not check for weird interactions between incompatible mouse
drivers, I find Michael's wish for coexisting old and new ADB mouse
drivers understandable:

When I try different kernels, 2.2.x ones without knowledge about the new
input layer, or 2.4.0 ones with or without new input layer switched on,
the different drivers for the ADB *keyboard* don't present any problem
(as long as I choose to work with raw-adb-keycodes). The whole
configuration is in the kernel, and even X works with either keyboard
model.

For the ADB *mouse*, this is quite different: When I want to use a
kernel with the new input layer for the mouse, it is not sufficient to
boot the correspondingly configured kernel. I also have to change a
couple of files in /etc to tell about the new mouse driver, in my case

/etc/devfsd.conf
/etc/sysconfig/mouse
/etc/X11/XF86Config

Then I have to restart devfsd, rm /dev/mouse, and restart gpm. (In this
order, and all this before starting X, of course).

When I go back to a kernel without new input layer, I have to change all
this back. This wouldn't be necessary if drivers for both /dev/adbmouse
and /dev/input/mice could coexist..

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Benjamin Herrenschmidt]

>For the ADB *mouse*, this is quite different: When I want to use a
>kernel with the new input layer for the mouse, it is not sufficient to
>boot the correspondingly configured kernel. I also have to change a
>couple of files in /etc to tell about the new mouse driver, in my case
>
>/etc/devfsd.conf
>/etc/sysconfig/mouse
>/etc/X11/XF86Config
>
>Then I have to restart devfsd, rm /dev/mouse, and restart gpm. (In this
>order, and all this before starting X, of course).
>
>When I go back to a kernel without new input layer, I have to change all
>this back. This wouldn't be necessary if drivers for both /dev/adbmouse
>and /dev/input/mice could coexist..

Well, that's the reason why I originally wanted this compatibility code.
However, after more thinking, I figured out that if we do that, all it
will result is yet another configuration mess with users and more support
emails ;)

Note that you can have the new input layer with 2.2 using my kernels. I
still have to verify what's up with Vojtech, but I beleive the input
layer is part of the USB backport, meaning that future "kernel.org"
2.2s+backport will provide the same functionality as 2.4.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Michael Schmitz]

> >When I go back to a kernel without new input layer, I have to change all
> >this back. This wouldn't be necessary if drivers for both /dev/adbmouse
> >and /dev/input/mice could coexist..
>
> Well, that's the reason why I originally wanted this compatibility code.
> However, after more thinking, I figured out that if we do that, all it
> will result is yet another configuration mess with users and more support
> emails ;)

We'll have the configuration mess either way. And few things are as
frustrating as answering the question 'why does the screen just keep
flashing on me when I boot this new 2.4 kernel, and how do I fix it' a
hundred times.

> Note that you can have the new input layer with 2.2 using my kernels. I

Which has working adbmouse if you remove all #ifndef INPUT_MOUSEDEV and
corresponding #endif in adbmouse.c.

> still have to verify what's up with Vojtech, but I beleive the input
> layer is part of the USB backport, meaning that future "kernel.org"
> 2.2s+backport will provide the same functionality as 2.4.

Meaning that functionality will be lost ... thanks for the warning.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Patches for 2.4.0-test7

[Franz Sirl]

At 12:43 28.08.00, Michael Schmitz wrote:

> > >When I go back to a kernel without new input layer, I have to change all
> > >this back. This wouldn't be necessary if drivers for both /dev/adbmouse
> > >and /dev/input/mice could coexist..
> >
> > Well, that's the reason why I originally wanted this compatibility code.
> > However, after more thinking, I figured out that if we do that, all it
> > will result is yet another configuration mess with users and more support
> > emails ;)
>
>We'll have the configuration mess either way. And few things are as
>frustrating as answering the question 'why does the screen just keep
>flashing on me when I boot this new 2.4 kernel, and how do I fix it' a
>hundred times.

But if you have a clean cut you can actually tell people what to do if they
use 2.4. And with people I mean the mass of users that nearly never switch
kernels, not developers like us :-). And if they switch they usually don't
ever switch back after a trial phase.

For 2.2 backwards compatibility is a must, but 2.4 is a major kernel
release and the right time to drop some backwards compatibility. And this
change doesn't even require updated user tools, it just requires slight
config changes.

> > Note that you can have the new input layer with 2.2 using my kernels. I
>
>Which has working adbmouse if you remove all #ifndef INPUT_MOUSEDEV and
>corresponding #endif in adbmouse.c.

In 2.2 adbmouse compatibility is there anyways, the only problem we are
still investigating is with Xpmac+adbmouse (well, Xpmac doesn't actually
use adbmouse right now), but this should be solved with the pending Xpmac
rev 11.

> > still have to verify what's up with Vojtech, but I beleive the input
> > layer is part of the USB backport, meaning that future "kernel.org"
> > 2.2s+backport will provide the same functionality as 2.4.
>
>Meaning that functionality will be lost ... thanks for the warning.

In 2.2 we will include backwards compatibility with adbmouse, only in 2.4
you will only have the either/or choice. We want to encourage people to use
the input layer in 2.4, so /dev/adbmouse can be dropped completely during 2.5.
And no functionality is lost (the mouse still works), just backwards
compatibility. And I completely agree with Linus on dropping backwards
compatibility as soon as possible. Maybe we would have functional and fast
XF3/4 display drivers by now for all of our (few) chips, if we would have
dropped Xpmac compatibility in 2.3.1?

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/