Re: CONFIG_PPC != Mac

Re: CONFIG_PPC != Mac

[Iain Sandoe]

On  Sat, Jul 29, 2000,  Geert Uytterhoeven wrote:

[...]
>
> The Master PPC Penguin decided to no longer allow to build machine specific
> kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> (`CONFIG_ALL_PPC').

Ah! so that's why it changed... it's not very helpful for the dmasound stuff
(as I'm sure you already know :-)

Iain.

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

Re: CONFIG_PPC != Mac

[Iain Sandoe]

>> The main problem so far is that I cannot get mouse button emulation to
>> work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
>> work if one goes over completely to the "linux" keycodes? I don't want
>> to do this yet, because it will make my system unusable with any other
>> kernel (or maybe unusable at all). Last time I tried, it took me several
>> hours to get a usable system back.
>
> ADB keyboard and mouse work (and button emulation works as well) with
> CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> but the box just crashed on me the second time in a row today. 2.2.17 sure
> is exciting.

2.2.17pre13ben2

Actually, (in contrast to my debacle with the Xserver) this has all gone
very smoothly for me - I'm using the new input layer and USB & ADB work
together beautifully on both B3 beige (with a cheepo USB card) and Lombard
(with a logitech wheel mouse).

It also works fine on my 9600 - which hasn't got the faintest clue of the
existence of USB :-)

The only gottcha I found was (as Ben suggested) that you *do* need to delete
the adbmouse entry in /dev rather than just rename it (OK, so I'm paranoid
sometimes).

I had a nasty crash with 2.2.17pre13ben2 on the Lombard (posted) but this
was IDE disk-related (and prob. something to do with sleep).

I suppose that I'm using Xpmac (still :-) rev.10 which might be why it's all
gone easily.

Iain.

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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > - USB mouse works as before both in X and for gpm when I link
> > /dev/usbmouse to /dev/input/mouse2. OK so far.
>
> Why not link it to /dev/input/mice? That's what's intended. Actually link
> /dev/mouse to /dev/input/mice and use /dev/mouse everywhere.

Because that breaks the X config for 2.2.15? (2.2.17 has a few other
shortcomings so I don't plan to use it permanently right now.) I'll sure
try using only /dev/input/mice later, just to see if the buttons 4 and 5
for the mouse wheel still work that way.

> > conditionals. Even the old way of mouse button emulation via /dev/adbmouse
> > still works, so why the #ifndef CONFIG_INPUT_MOUSEDEV to remove a fully
> > functional feature that doesn't even interfere with the new input layer
> > for all I can see?
>
> Well, that wasn't the goal here, I wanted a single gpm and X config for all
> mice, and I wanted as much old cruft removed as possible for the
> CONFIG_NEW_INPUT_LAYER case, it has been there for far too long. And who,
> except developers, want's to use old 2.2 kernels if the new kernel works?

Who wants to use new 2.2 kernels if they do things like freeze for no
apparent reason, or wake up from sleep with the display remaining off? I
can't remember a crash with 2.2.15, while 2.2.17 doesn't seem as stable.
At least while I work on fixing 2.2.17 related problems I'd like to fall
back on 2.2.15 for real work.

Removing old cruft is all fine and dandy - for 2.4, IMHO. Please note that
I've not said the new input layer shouldn't be introduced in 2.2, just
that things working before shouldn't break (like adbmouse with the input
layer, or USB without). But perhaps I've just been lucky with previous
2.2.x experimental versions that didn't break.

	Michael


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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> At 18:40 31.07.00, Michael Schmitz wrote:
> > > I am fighting with the "new input layer" right now, although I don't
> > > quite understand why this thing is being inflicted upon innocent ADB
> > > users.
> >
> >My question exactly.
>
> But we are talking about developer trees (2.4 and benh) right now, or? I
> have no problem breaking things here for some time, as long as a working
> version ends up in the stable trees.

I have no problem with you breaking things in the developer trees either,
but I was talking about 2.2.17 which also appears to have the new input
stuff, and that's what bothers me. I already know I have to make a number
of changes to my system with 2.4 (devfs will probably be the first
stumbling block) but didn't expect major breakage with 2.2 kernels.

> >ADB keyboard and mouse work (and button emulation works as well) with
> >CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> >USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> >added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> >not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> >but the box just crashed on me the second time in a row today. 2.2.17 sure
> >is exciting.
>
> I'll try myself without CONFIG_NEW_INPUT_LAYER set later. But I wonder why
> your USB mouse would no longer work. It certainly works for me in console
> and XF4. X or console? Xpmac (which rev?) or XFree? Did you link
> /dev/usbmouse to /dev/input/mice?

Neither gpm nor XFree (never used Xpmac) have the USB mouse working. I've
used /dev/input/mice, /dev/hidbp-mse-0, and the miscdev USB mouse device,
with various combinations of config options in the USB sections, to no
avail.

	Michael


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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> >ADB keyboard and mouse work (and button emulation works as well) with
> >CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> >USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> >added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> >not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> >but the box just crashed on me the second time in a row today. 2.2.17 sure
> >is exciting.
>
> I'll try myself without CONFIG_NEW_INPUT_LAYER set later. But I wonder why
> your USB mouse would no longer work. It certainly works for me in console
> and XF4. X or console? Xpmac (which rev?) or XFree? Did you link
> /dev/usbmouse to /dev/input/mice?

OK, I've tried with CONFIG_NEW_INPUT_LAYER set in the meantime, here's
what I got (on 2.2.17pre13-ben2, to be precise):

- USB mouse works as before both in X and for gpm when I link
/dev/usbmouse to /dev/input/mouse2. OK so far.

- gpm takes input from trackpad, USB mouse and emulation buttons without a
hitch if I use /dev/input/mice as the device. I can most definitely live
with that. No serious, this is a major improvement over the previous
scheme (including Paul's idea to copy all USB mouse packets to the
adbmouse channel, too). I think can see where the new input layer is
heading, and think it was about time for a major rewrite of the keyboard
driver mess, plus it obsoletes the ADB device hack I sent to Paul so that
saves me patching it up for 2.4. I'm mostly for it, but:

- the showstopper: In order to keep my X config backwards compatible with
older kernels, I need /dev/adbmouse as busmouse protocol device. It's dead
now ... but can reactivated if you remove the #ifndef CONFIG_INPUT_MOUSEDEV
conditionals. Even the old way of mouse button emulation via /dev/adbmouse
still works, so why the #ifndef CONFIG_INPUT_MOUSEDEV to remove a fully
functional feature that doesn't even interfere with the new input layer
for all I can see?

Side note: if you use /dev/input/mouse1 to get the trackpad data you will
miss the mouse emulation packets that are on /dev/input/mouse0. That may
be why emulation appeared broken to some.

	Michael

P.S.: the list seems broken right now, any idea who should be notified?


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

Re: CONFIG_PPC != Mac

[Iain Sandoe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="", Size: 899 bytes --]


On  Sun, Jul 30, 2000,  Geert Uytterhoeven wrote:
> On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
>> Geert Uytterhoeven wrote:
>> > The Master PPC Penguin decided to no longer allow to build machine specific
>> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
>> > (`CONFIG_ALL_PPC').
[snip]
> Personally I'd more like a configuration where you can select whatever you
> want of
>
>   - PowerMac (CONFIG_PMAC)
>   - PReP (CONFIG_PREP)
>   - MTX (CONFIG_MTX)
>   - CHRP (CONFIG_CHRP)
>   - Gemini (CONFIG_GEMINI)
>   - EST8260 (CONFIG_EST8260)
>   - APUS (CONFIG_APUS)
>
> with of course some extra logic to prevent illegal combinations.

This would definitely get my vote too.  There are too many cases where you
can enable conflicting build options at present - it causes much
frustration.

Iain.

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

Re: CONFIG_PPC != Mac

[Johnnie Peters]

Iain Sandoe wrote:

> On  Sun, Jul 30, 2000,  Geert Uytterhoeven wrote:
> > On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> >> Geert Uytterhoeven wrote:
> >> > The Master PPC Penguin decided to no longer allow to build machine specific
> >> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> >> > (`CONFIG_ALL_PPC').
> [snip]
> > Personally I'd more like a configuration where you can select whatever you
> > want of
> >
> >   - PowerMac (CONFIG_PMAC)
> >   - PReP (CONFIG_PREP)
> >   - MTX (CONFIG_MTX)
> >   - CHRP (CONFIG_CHRP)
> >   - Gemini (CONFIG_GEMINI)
> >   - EST8260 (CONFIG_EST8260)
> >   - APUS (CONFIG_APUS)
> >
> > with of course some extra logic to prevent illegal combinations.
>
> This would definitely get my vote too.  There are too many cases where you
> can enable conflicting build options at present - it causes much
> frustration.
>
> Iain.
>

There are also other considerations.  While there is almost always enough memory to

carry the extra functionality it is not always the case.  Some boards are being
booted
out of rom and may still only have a limited amount of space to hold the kernel.
In any
case do we really want to wast the space.

As Dan stated it also causes a lot of extra work on ports to new boards that
probably
do not need all the configuration parameters for the pmacs.

Johnnie

MontaVista Software, Inc.


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

CONFIG_PPC != Mac

[Dan Malek]

Or vice versa....

So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
we can't make the assumption that CONFIG_PPC is a Macintosh.  It
breaks all PowerPC embedded systems (or anything that isn't a recent
Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
thing?

Can we quickly resolve this?  The BK tree doesn't build for many
systems right now.

Thanks.


	-- Dan

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

Re: CONFIG_PPC != Mac

[Tom Rini]

On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:

> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
> breaks all PowerPC embedded systems (or anything that isn't a recent
> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
> thing?

Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
right now, IIRC.)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 11:38 AM -0500 7/29/2000, Tom Rini wrote:
>On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
>
>> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
>> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
>> breaks all PowerPC embedded systems (or anything that isn't a recent
>> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
>> thing?
>
>Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
>right now, IIRC.)

Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
&& __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.

On the other hand, using a CONFIG option all over the place is probably the
wrong answer for this. I'd rather see something along the lines of:

#ifdef CONFIG_PMAC
#define MACH_IS_PMAC (machtype == MACH_PMAC)
#else
#define MACH_IS_PMAC 0
#endif

...

if (MACH_IS_PMAC) {
	/* do powermac stuff here */
}

which may already exist, I haven't ever bothered to look. Anyways, it would
let you either strip out powermac code, or build a kernel that works both
on powermacs and non-powermacs alike, depending on which you want.


Or whatever.

Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Tony Mantler wrote:

> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.

Ahhhhh....I get it.  Apologies to the m68k folks....
OK....let me think about this and work on some alternatives.  So, it
is OK to assume CONFIG_MAC implies m68k?

Thanks.


	-- Dan

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

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
>Tony Mantler wrote:
>
>> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
>> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
>> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>
>Ahhhhh....I get it.  Apologies to the m68k folks....
>OK....let me think about this and work on some alternatives.  So, it
>is OK to assume CONFIG_MAC implies m68k?

At the moment, it appears yes. via-cuda.c is a good example of this. On the
other hand, valkyriefb.c uses __mc68000 instead, so go fig.


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


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

Re: CONFIG_PPC != Mac

[Martin Costabel]

Tony Mantler wrote:
>
> At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
> >Tony Mantler wrote:
> >
> >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> >> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
> >
> >Ahhhhh....I get it.  Apologies to the m68k folks....
> >OK....let me think about this and work on some alternatives.  So, it
> >is OK to assume CONFIG_MAC implies m68k?
>
> At the moment, it appears yes. via-cuda.c is a good example of this. On the
> other hand, valkyriefb.c uses __mc68000 instead, so go fig.

??? Care to explain? What kernel are you talking about? I don't find any
CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

IMHO, there seems to be a lot of confusion right now with config options
in the latest bk kernel, like you can still choose CONFIG_ADBMOUSE, but
no longer CONFIG_ADB_KEYBOARD which is needed at several places,
however.

--
Martin

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

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 9:24 PM -0500 7/29/2000, Martin Costabel wrote:
>Tony Mantler wrote:
>>
>> At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
>> >Tony Mantler wrote:
>> >
>> >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
>> >> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
>> >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>> >
>> >Ahhhhh....I get it.  Apologies to the m68k folks....
>> >OK....let me think about this and work on some alternatives.  So, it
>> >is OK to assume CONFIG_MAC implies m68k?
>>
>> At the moment, it appears yes. via-cuda.c is a good example of this. On the
>> other hand, valkyriefb.c uses __mc68000 instead, so go fig.
>
>??? Care to explain? What kernel are you talking about? I don't find any
>CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

2.3.99-pre5, Linus edition. just happens to be what I have handy atm.

I should certainly hope there would be some CONFIG_MAC in the kernel source
somewhere, it should have been there since 2.0.something atleast... unless
maybe Linus decided he doesn't like 68k macs and stripped it all out! :o ;)


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Martin Costabel wrote:

> ??? Care to explain? What kernel are you talking about? I don't find any
> CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

I originally stated I was using the 2.4.0-test5 from BitKeeper......
The CONFIG_MAC is in some Makefiles, which causes drivers/macintosh
to be used.


> IMHO, there seems to be a lot of confusion right now with config options
> in the latest bk kernel,

So, I'm not alone here :-)?


	-- Dan

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

Re: CONFIG_PPC != Mac

[Franz Sirl]

At 04:24 30.07.00, Martin Costabel wrote:

>Tony Mantler wrote:
> >
> > At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
> > >Tony Mantler wrote:
> > >
> > >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC
> with
> > >> PPC, except that it would be easy to assume that CONFIG_MAC ==
> CONFIG_MAC
> > >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
> > >
> > >Ahhhhh....I get it.  Apologies to the m68k folks....
> > >OK....let me think about this and work on some alternatives.  So, it
> > >is OK to assume CONFIG_MAC implies m68k?
> >
> > At the moment, it appears yes. via-cuda.c is a good example of this. On the
> > other hand, valkyriefb.c uses __mc68000 instead, so go fig.
>
>??? Care to explain? What kernel are you talking about? I don't find any
>CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.
>
>IMHO, there seems to be a lot of confusion right now with config options
>in the latest bk kernel, like you can still choose CONFIG_ADBMOUSE, but
>no longer CONFIG_ADB_KEYBOARD which is needed at several places,
>however.

What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
input layer Makefile setup in drivers/macintosh needs some refinement vs.
m68k though (hopefully m68k people will use my new stuff too). The possible
selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
tree, I conditionalized it on CONFIG_MAC.

BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
CONFIG_PPC?

Franz.


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

Re: CONFIG_PPC != Mac

[Martin Costabel]

Franz Sirl wrote:
[]
> What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
> PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
> input layer Makefile setup in drivers/macintosh needs some refinement vs.
> m68k though (hopefully m68k people will use my new stuff too). The possible
> selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
> tree, I conditionalized it on CONFIG_MAC.

Yes, I had CONFIG_ADBMOUSE=y, and this needed mac_keyb.c which was not
included unless CONFIG_ADB_KEYBOARD was chosen.

I am fighting with the "new input layer" right now, although I don't
quite understand why this thing is being inflicted upon innocent ADB
users.

I am trying to use it in compatibility mode, so that I can still boot
into other kernels (if I see this right, for ADB it doesn't exist
outside of BenH's 2.2.17 tree and the linuxppc_2_3 tree. How sure is it
that this will be accepted into the mainstream kernel?). There are still
some problems:

After booting, some keys don't work: The "a" key that was mentioned
before (it is the "q" here on my French keyboard), but also all the
function keys and most keypad keys. Some of them don't produce keycodes,
some of them weird ones.

After starting X, the situation remained the same, although xev didn't
show the same keycodes or lack of them as showkey. I then switched
/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes on and off (had to
learn to type "j" for <return> first to go back) and left and reentered
X a couple of times. After a while, all keys started to work correctly.
I'll do some more testing what makes them work.

The main problem so far is that I cannot get mouse button emulation to
work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
work if one goes over completely to the "linux" keycodes? I don't want
to do this yet, because it will make my system unusable with any other
kernel (or maybe unusable at all). Last time I tried, it took me several
hours to get a usable system back.

--
Martin

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

Re: CONFIG_PPC != Mac

[Franz Sirl]

At 15:11 31.07.00, Martin Costabel wrote:
>Franz Sirl wrote:
>[]
> > What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
> > PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
> > input layer Makefile setup in drivers/macintosh needs some refinement vs.
> > m68k though (hopefully m68k people will use my new stuff too). The possible
> > selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
> > tree, I conditionalized it on CONFIG_MAC.
>
>Yes, I had CONFIG_ADBMOUSE=y, and this needed mac_keyb.c which was not
>included unless CONFIG_ADB_KEYBOARD was chosen.
>
>I am fighting with the "new input layer" right now, although I don't
>quite understand why this thing is being inflicted upon innocent ADB
>users.

2.4 users are not innocent :-). As I said, just don't turn on
CONFIG_ADBMOUSE. I'm doing that right now, cause the kernel uses linux
keycodes already internally now, and they will show up externally somewhere
during 2.5, so doing it for 2.4 with backwards compatibility on by default
is the best thing to do.

>I am trying to use it in compatibility mode, so that I can still boot
>into other kernels (if I see this right, for ADB it doesn't exist
>outside of BenH's 2.2.17 tree and the linuxppc_2_3 tree. How sure is it
>that this will be accepted into the mainstream kernel?). There are still
>some problems:
>
>After booting, some keys don't work: The "a" key that was mentioned
>before (it is the "q" here on my French keyboard), but also all the
>function keys and most keypad keys. Some of them don't produce keycodes,
>some of them weird ones.

I fixed that in my tree too, just got the condition in pmac_setup.c wrong,
it should be if (!keyboard_sends_linux_keycodes) ..., just a typo, will be
fixed later today.

>After starting X, the situation remained the same, although xev didn't
>show the same keycodes or lack of them as showkey. I then switched
>/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes on and off (had to
>learn to type "j" for <return> first to go back) and left and reentered
>X a couple of times. After a while, all keys started to work correctly.
>I'll do some more testing what makes them work.

See above, switching /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes to
1 and then back to 0 probably fixes it.

>The main problem so far is that I cannot get mouse button emulation to
>work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
>work if one goes over completely to the "linux" keycodes? I don't want
>to do this yet, because it will make my system unusable with any other
>kernel (or maybe unusable at all). Last time I tried, it took me several
>hours to get a usable system back.

Mouse button emulation works for me and it works in both keycode modes, in
2.4 the adb_buttons kernel arg is gone though.

Franz.


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

Re: CONFIG_PPC != Mac

[Andreas Tobler]

Franz Sirl wrote:

> 2.4 users are not innocent :-). As I said, just don't turn on
> CONFIG_ADBMOUSE. I'm doing that right now, cause the kernel uses linux
> keycodes already internally now, and they will show up externally somewhere
> during 2.5, so doing it for 2.4 with backwards compatibility on by default
> is the best thing to do.

Turning CONFIG_ADBMOUSE off results in a nice kernel panic with two additional
keyboards connected to the adb-port of my wallstreet :-) (No additional mouse
connected)

With only the internal kbd it works so far even with the new LAYER maps.

Andreas

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

Re: CONFIG_PPC != Mac

[Andreas Tobler]

Franz Sirl wrote:
> >Turning CONFIG_ADBMOUSE off results in a nice kernel panic with two additional
> >keyboards connected to the adb-port of my wallstreet :-) (No additional mouse
> >connected)
>
> Now that is interesting. Did it work with Ben's 2.2? Were the keyboards
> plugged in at boot time? Modules or compiled in? Can you give a bit more
> details please?

Sure I can ;-)
Situation: Wallstreet I internal ISO-kbd , ISO-kbd, ANSI-kbd, (with and
without MouseMan)
Built-in!

- 2.2.17pre13-ben2 works flawless, no problem so far except the KP_equal.....

- 2.4.0test5 synced today no additional kbd on boot works
- 2.4.0test5 with additional kbd & MouseMan plugged in AFTER boot works
- 2.4.0test5 with additional kbd & MouseMan plugged on boot (means
before) panics.
- 2.4.0test5 with additional kbd & MouseMan plugged on boot, passing
console=ttyS0 as kernel args works
- 2.4.0test5 with additional kbd & MouseMan plugged on boot, passing
console=tty0 and console=ttyS0 as kernel args panics, see below.

The console stuff was added to collect an eventual panic :-)

The config I have to grab from the linux side

Andreas

---------

log with only console=ttyS0:

ADB keyboard at 2, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input1: ADB HID on ID 2:2.c4
ADB keyboard at 12, handler set to 3
Detected ADB keyboard, type ANSI.
input2: ADB HID on ID 12:2.03
ADB keyboard at 13, handler 1
Detected ADB keyboard, type ANSI.
input3: ADB HID on ID 13:2.01
ADB keyboard at 15, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input4: ADB HID on ID 15:2.05
input5: ADB HID on ID 7:7.1f
ADB mouse at 3, handler set to 4 (trackman/mouseman)
input6: ADB HID on ID 3:3.04
ADB mouse at 14, handler set to 4 (trackpad)
input7: ADB HID on ID 14:3.04
Macintosh non-volatile memory driver v1.0
event0: Event device for input7
event1: Event device for input6
event2: Event device for input5
event3: Event device for input4
event4: Event device for input3
event5: Event device for input2
event6: Event device for input1
event7: Event device for input0
usb.c: registered new driver hid
keybdev.c: Adding keyboard: input4
keybdev.c: Adding keyboard: input3
keybdev.c: Adding keyboard: input2
keybdev.c: Adding keyboard: input1
mouse0: PS/2 mouse device for input7
mouse1: PS/2 mouse device for input6
mouse2: PS/2 mouse device for input0
mice: PS/2 mouse device common for all mice

log with console=tty0 & console=ttyS0:

ADB keyboard at 2, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input1: ADB HID on ID 2:2.c4
NIP: C0154254 XER: 00000000 LR: C01541A0 REGS: c055f9e0 TRAP: 0300
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c055e000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C01541A0 C055FA90 C055E000 00000000 00000001 0000003A 00000001 081A7300
GPR08: C0270000 C0270000 00000000 000000DC 22828042 002CB0A8 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00001032 0055FBC0 00000000 C0004BE4
GPR24: C0005A00 00000001 C055FBD0 00000001 00000034 0000003A 00000001 00000000

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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> I am fighting with the "new input layer" right now, although I don't
> quite understand why this thing is being inflicted upon innocent ADB
> users.

My question exactly.

> The main problem so far is that I cannot get mouse button emulation to
> work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
> work if one goes over completely to the "linux" keycodes? I don't want
> to do this yet, because it will make my system unusable with any other
> kernel (or maybe unusable at all). Last time I tried, it took me several
> hours to get a usable system back.

ADB keyboard and mouse work (and button emulation works as well) with
CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
but the box just crashed on me the second time in a row today. 2.2.17 sure
is exciting.

	Michael


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

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Mon, 31 Jul 2000, Franz Sirl wrote:
> BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
> CONFIG_PPC?

And what makes the difference between a `desktop' and an `embedded' PPC here?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:
>
> On Mon, 31 Jul 2000, Franz Sirl wrote:
> > BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
> > CONFIG_PPC?
>
> And what makes the difference between a `desktop' and an `embedded' PPC here?


I hope we don't do this, as I don't think that is a very good
distinction either.  I prefer some of the other suggestions, where
we simply have mix-n-match configuration options.  Select a board
and processor type and go from there.

I have had the opportunity lately to use some of the other Linux
processor architecture configurations.  The Linux PowerPC configuration
really isn't too bad, and I would prefer just a small evolution.  If
you want to see some bad configuration and hard to use environments,
go visit some of the other emerging architectures.......

I think even some of the "source restructuring" that has been discussed
could also be mitigated with a more logical set of configuration options.


	-- Dan

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

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Sat, 29 Jul 2000, Tony Mantler wrote:
> At 11:38 AM -0500 7/29/2000, Tom Rini wrote:
> >On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
> >
> >> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
> >> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
> >> breaks all PowerPC embedded systems (or anything that isn't a recent
> >> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
> >> thing?
> >
> >Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
> >right now, IIRC.)
>
> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>
> On the other hand, using a CONFIG option all over the place is probably the
> wrong answer for this. I'd rather see something along the lines of:
>
> #ifdef CONFIG_PMAC
> #define MACH_IS_PMAC (machtype == MACH_PMAC)
> #else
> #define MACH_IS_PMAC 0
> #endif
>
> ...
>
> if (MACH_IS_PMAC) {
> 	/* do powermac stuff here */
> }
>
> which may already exist, I haven't ever bothered to look. Anyways, it would

Ah, the 1996 m68k scheme :-) [cfr. include/asm-m68k/setup.h]

> let you either strip out powermac code, or build a kernel that works both
> on powermacs and non-powermacs alike, depending on which you want.

The Master PPC Penguin decided to no longer allow to build machine specific
kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
(`CONFIG_ALL_PPC').

Given the flexibility I was used to on m68k[*], I find this a pity as well...

Gr{oetje,eeting}s,

						Geert

[*] Mix-'n-match any of:

    bool 'Amiga support' CONFIG_AMIGA
    bool 'Atari support' CONFIG_ATARI
    bool 'Macintosh support' CONFIG_MAC
    bool 'Apollo support' CONFIG_APOLLO
    bool 'VME (Motorola and BVM) support' CONFIG_VME
    bool 'HP9000/300 support' CONFIG_HP300
    bool 'Sun3x support' CONFIG_SUN3X
    bool 'Q40/Q60 support' CONFIG_Q40

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: CONFIG_PPC != Mac

[Michel Dänzer]

Geert Uytterhoeven wrote:

> The Master PPC Penguin decided to no longer allow to build machine specific
> kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> (`CONFIG_ALL_PPC').

Where does APUS fit in there?


Michel


--
There's no place like ~
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

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

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > The Master PPC Penguin decided to no longer allow to build machine specific
> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> > (`CONFIG_ALL_PPC').
>
> Where does APUS fit in there?

APUS is something different (CONFIG_APUS, cfr. arch/ppc/config.in). Currently
it's not possible to build one kernel that supports both APUS and any other
machine type anyway.

So currently you have to compile a kernel for _either_

    PowerMac/PReP/MTX/CHRP (CONFIG_ALL_PPC)
 or Gemini (CONFIG_GEMINI)
 or EST8260 (CONFIG_EST8260)
 or APUS (CONFIG_APUS)

Personally I'd more like a configuration where you can select whatever you
want of

  - PowerMac (CONFIG_PMAC)
  - PReP (CONFIG_PREP)
  - MTX (CONFIG_MTX)
  - CHRP (CONFIG_CHRP)
  - Gemini (CONFIG_GEMINI)
  - EST8260 (CONFIG_EST8260)
  - APUS (CONFIG_APUS)

with of course some extra logic to prevent illegal combinations.

The main reason why the Master PPC Penguin chose for the CONFIG_ALL_PPC option
was to be able to compile one kernel that would run on all his machines,
instead of having to compile multiple kernels, one for each machine.
I don't understand why he didn't want the flexibele scheme above, since it
would support anything you want, including his favorite configuration.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:

> Given the flexibility I was used to on m68k[*], I find this a pity as well...


Well, it looks like I opened up a big can of worms...........

I guess this is something that will get discussed as part of
"restructuring" the PowerPC source tree when we jump into 2.5.xx.
However, I need some kind of a simple solution that will help me with
the embedded processors that will no longer build in the 2.4.xx
kernel.  I know there must be some embedded Linux m68k boards that
have a similar challenge that I may be able to use for insight.

What I would like to do in the short term, is create a CONFIG_PPCMAC
that has the sole purpose of including the drivers/macintosh software,
or perhaps overload the CONFIG_ALL_PPC to do this.  Perhaps I will
look at what CONFIG_PPC really means, and not define this for embedded
boards (although this sounds wrong).

Thanks for the comments.  We'll be back :-).


	-- Dan

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

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Mon, 31 Jul 2000, Dan Malek wrote:
> Geert Uytterhoeven wrote:
> > Given the flexibility I was used to on m68k[*], I find this a pity as well...
> Well, it looks like I opened up a big can of worms...........
>
> I guess this is something that will get discussed as part of
> "restructuring" the PowerPC source tree when we jump into 2.5.xx.

Note that there was a time when we did have separate CONFIG_PMAC, CONFIG_PREP
and CONFIG_CHRP switches. I liked it, since it allowed to customize your kernel
more precisely.

> However, I need some kind of a simple solution that will help me with
> the embedded processors that will no longer build in the 2.4.xx
> kernel.  I know there must be some embedded Linux m68k boards that
> have a similar challenge that I may be able to use for insight.

AFAIK there are no embedded m68k boards. There are embedded uClinux boards,
though, but these are still at the 2.0.38 level.

> What I would like to do in the short term, is create a CONFIG_PPCMAC
> that has the sole purpose of including the drivers/macintosh software,

Please call it CONFIG_PMAC, like it used to be.

BTW, ADB code should be in driverd/adb/, cfr. all other bus types. It should be
protected using CONFIG_ADB, which should be configurable depending on either of
CONFIG_MAC, CONFIG_PMAC, CONFIG_CHRP or CONFIG_NEXT in
arch/{m68k,ppc}/config.in. That way you can leave out ADB support if you don't
need it (e.g. for server PowerMac boxes, and for CHRP boxes that use the PS/2
port only).

> or perhaps overload the CONFIG_ALL_PPC to do this.  Perhaps I will
> look at what CONFIG_PPC really means, and not define this for embedded
> boards (although this sounds wrong).

CONFIG_PPC is always set to `y' on the PPC platform. It's a substitute for
checking the arch type. I don't really see why it was invented, since the same
thing can easily be done using `#ifdef __powerpc__' in sources and `ifeq
($(ARCH),PPC)' in makefiles. Besides, CONFIG_PPC has the unwanted side effect
of making more sources depend on config.h.

So far my opinion...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:

> Please call it CONFIG_PMAC, like it used to be.

BenH beat all of us to this :-).  He made the modifications for
the new "unified" CONFIG_ALL_PPC........


	-- Dan

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

Re: CONFIG_PPC != Mac

[Ani Joshi]

On Wed, 2 Aug 2000, Geert Uytterhoeven wrote:

> Note that there was a time when we did have separate CONFIG_PMAC, CONFIG_PREP
> and CONFIG_CHRP switches. I liked it, since it allowed to customize your kernel
> more precisely.

Also note that one can use the __pmac __prep attributes which were added
to the kernel a long time ago, and __chrp which I recently added.  Granted
these wont 'weed out' code like cpp does but you can still get rid of
excess kernel data upon boot.


ani


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

Re: CONFIG_PPC != Mac

[Benjamin Herrenschmidt]

>BTW, ADB code should be in driverd/adb/, cfr. all other bus types. It
>should be
>protected using CONFIG_ADB, which should be configurable depending on
>either of
>CONFIG_MAC, CONFIG_PMAC, CONFIG_CHRP or CONFIG_NEXT in
>arch/{m68k,ppc}/config.in. That way you can leave out ADB support if you
don't
>need it (e.g. for server PowerMac boxes, and for CHRP boxes that use the PS/2
>port only).

I don't think there's real need anymore for an adb directory. The only
file in it would be adb.c. The mouse and kbd drivers are moving to input,
the controller drivers (Cuda,PMU) do not only ADB but all sort of other
machine admin tasks (like power control, I2C, ...) and so are needed even
whithout ADB support as part of "PowerMac" support. Cuda can be shared
with m68k, maybe PMU too, so drivers/macintosh is not a so bad place for it.


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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > Given the flexibility I was used to on m68k[*], I find this a pity as well...
>
> Well, it looks like I opened up a big can of worms...........
>
> I guess this is something that will get discussed as part of
> "restructuring" the PowerPC source tree when we jump into 2.5.xx.

While I also enjoyed the flexibility on m68k, some of it was paid for in
terms of increased complexity in head.S and entry.S (and especially head.S
wasn't a bit pretty). I'm not sure how your trouble with the embedded
systems can be solved, we kept separate head.S versions for Macs and other
machines for a while as well because things just got too confusing. Maybe
we need to keep separate versions for embedded and other systems here?

	Michael


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

Re: CONFIG_PPC != Mac

[Tom Gall]

Michael Schmitz wrote:
>
> > > Given the flexibility I was used to on m68k[*], I find this a pity as well...
> >
> > Well, it looks like I opened up a big can of worms...........
> >
> > I guess this is something that will get discussed as part of
> > "restructuring" the PowerPC source tree when we jump into 2.5.xx.
>
> While I also enjoyed the flexibility on m68k, some of it was paid for in
> terms of increased complexity in head.S and entry.S (and especially head.S
> wasn't a bit pretty). I'm not sure how your trouble with the embedded
> systems can be solved, we kept separate head.S versions for Macs and other
> machines for a while as well because things just got too confusing. Maybe
> we need to keep separate versions for embedded and other systems here?

Hi All,

  I think we don't want to get too carried away with pulling things
apart here. Afterall I think we'd all like to be able to continue to
pick up a distro with a bootable kernel that works over a wide variety
of machines instead of 10 different kernels to choose from depending on
which box you've got.

  Now obvoiusly I'm going a little overboard here but hopefully you
might see what I'm saying. Granted embedded boxes aren't going to care
about booting from the install cd but I think the rest of us sure do!

--
Hakuna Matata,

Tom

-----------------------------------------------------------
Linux Guy          "My heart is human, my blood is boiling,
tgall@uswest.net    my brain IBM" -- Mr Roboto, Styxx

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

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > While I also enjoyed the flexibility on m68k, some of it was paid for in
> > terms of increased complexity in head.S and entry.S (and especially head.S
> > wasn't a bit pretty). I'm not sure how your trouble with the embedded
> > systems can be solved, we kept separate head.S versions for Macs and other
> > machines for a while as well because things just got too confusing. Maybe
> > we need to keep separate versions for embedded and other systems here?
>
> Hi All,
>
>   I think we don't want to get too carried away with pulling things
> apart here. Afterall I think we'd all like to be able to continue to
> pick up a distro with a bootable kernel that works over a wide variety
> of machines instead of 10 different kernels to choose from depending on
> which box you've got.

That's exactly what won't work now. A kernel built for PowerMac won't work
on embedded systems or APUS, and maybe not even on PReP or CHRP.

>   Now obvoiusly I'm going a little overboard here but hopefully you
> might see what I'm saying. Granted embedded boxes aren't going to care
> about booting from the install cd but I think the rest of us sure do!

I don't see where we would conflict, all I said was maybe keep embedded
separate. By all means unify the rest if at all possible.

	Michael


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

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Thu, 3 Aug 2000, Michael Schmitz wrote:
> > > While I also enjoyed the flexibility on m68k, some of it was paid for in
> > > terms of increased complexity in head.S and entry.S (and especially head.S
> > > wasn't a bit pretty). I'm not sure how your trouble with the embedded
> > > systems can be solved, we kept separate head.S versions for Macs and other
> > > machines for a while as well because things just got too confusing. Maybe
> > > we need to keep separate versions for embedded and other systems here?
> >
> >   I think we don't want to get too carried away with pulling things
> > apart here. Afterall I think we'd all like to be able to continue to
> > pick up a distro with a bootable kernel that works over a wide variety
> > of machines instead of 10 different kernels to choose from depending on
> > which box you've got.

Note that I never said the various CONFIG_* options have to be mutual
exclusive. Enable them all for a generic kernel for a distro, enable what you
need only for a machine-specific kernel.

> That's exactly what won't work now. A kernel built for PowerMac won't work
> on embedded systems or APUS, and maybe not even on PReP or CHRP.

PowerMac kernels should work on PReP and CHRP as well.

> >   Now obvoiusly I'm going a little overboard here but hopefully you
> > might see what I'm saying. Granted embedded boxes aren't going to care
> > about booting from the install cd but I think the rest of us sure do!
>
> I don't see where we would conflict, all I said was maybe keep embedded
> separate. By all means unify the rest if at all possible.

The rest is unified. But it's so unified that I can't get rid of e.g. all
PowerMac-only code when I want to compile a kernel for a CHRP box. Much
PowerMac specific stuff is indeed freed up later when the pmac section is
released, but that's all.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: CONFIG_PPC != Mac

[Dan Malek]

Tom Rini wrote:

> Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
> right now, IIRC.)

Sorry, I guess I haven't looked at it in a while.....I just noticed
this with the recent 2.4.0-test5 BitKeeper tree.

All CONFIG_PPC builds include drivers/macintosh, and I guess there are
more changes happening there that require additional configuration
options.  For example, you can't build a PowerPC without Machintosh
and USB (and ADB, and keyboards, and....).  So, when I have a PowerPC
that isn't a Mac, I can't link a kernel unless I have all of these
devices configured.  Then, it likes to probe for this stuff, or look
for OF device trees, or something else I don't have.

However, there is a good side :-).  For the first time I am able to
build a kernel without _any_  Mac drivers, which is really nice.

I modified the Makefiles to remove the line:
	DRIVERS-$(CONFIG_PPC) += drivers/macintosh/macintosh.o

and other places where CONFIG_PPC included the macintosh subdir.


This at least works for my embedded systems.  The interesting part
is that in all of these cases, there is an identical Makefile line
or logic for CONFIG_MAC, so I kind of assumed that if you really want
Mac drivers, you could just configure this.....

I am now about to experiment with building for my iMacs and G4s.
I would like to know what people think CONFIG_MAC or CONFIG_PPC or
some of these others are supposed to mean, or assumptions they make.

Thanks.


	-- Dan

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