Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Michael Sokolov]

Troy Benjegerdes <hozer@drgw.net> wrote:

> Above all, *readable* code, because otherwise someone changes something,
> and inadvertently breaks machines that they don't have to test on.

We've got this one settled in favor of ELF section magic to add machines, which
works for both of us.

> If better functionality for the user is your goal, you can't achieve it by
> designing code around that goal. (Unless, of course, you're Apple computer
> and have large resources for QA and testing, and design the hardware
> yourself)

I do design the hardware myself now. But the company I take example from is
DEC, not Apple.

MS

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

2.5 (or beyond) arch-specific boot modules

[Troy Benjegerdes]

On Mon, Apr 15, 2002 at 11:11:48AM -0700, Michael Sokolov wrote:
>
> Troy Benjegerdes <hozer@drgw.net> wrote:
>
> > Above all, *readable* code, because otherwise someone changes something,
> > and inadvertently breaks machines that they don't have to test on.
>
> We've got this one settled in favor of ELF section magic to add machines, which
> works for both of us.

Good.

Something along these lines we might want to think about eventually is if
the 2.5 changes for initramfs and making everything a module actually go
through is to make all the board-specific init a module.

Granted, this brings up all kinds of other issues, but I do think they can
be dealt with.

boot would probably go something like this:

Init MMU
find initramfs filesystem image
unpack it
load init module to figure out what machine we are
load board-specific init modules
init pci & other IO
etc..


>
> > If better functionality for the user is your goal, you can't achieve it by
> > designing code around that goal. (Unless, of course, you're Apple computer
> > and have large resources for QA and testing, and design the hardware
> > yourself)
>
> I do design the hardware myself now. But the company I take example from is
> DEC, not Apple.

Heh ;)

Well, for technical users, that's great.. DEC never did much for the
'average' computer user. ;)

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

[Just some code comments for now, actual comments in another mail]

> ChangeSet
>   1.925 02/04/05 23:09:25 msokolov@helium.harhan.org +60 -0
[snip]
>   arch/ppc/kernel/setup.c
>     1.105 02/04/01 00:01:18 msokolov@helium.harhan.org +49 -5
>     Add generic PPC32 config

We shouldn't be #ifdef'ing externs, since it doesn't matter.  The
pmac/prep/chrp ones were hidden just because the line above was, iirc.

And the one downside to the GENERIC_PPC32 platform_init, is that we're
back to adding:
#ifdef CONFIG_x
 case _MACH_x:
  x_init(...);
  break;
#endif

Which I think Paul was happy to see die :)

[snip]
>   arch/ppc/config.in
>     1.127 02/03/31 23:58:43 msokolov@helium.harhan.org +18 -21
>     Add generic PPC32 config, implemented for
>     Adirondack, EV-64260A, and K2

Do any of these boards actually have an ISA slot?  IIRC, CONFIG_ISA is
used for stuff which could be plugged into an ISA slot, not so much
things that could be on the ISA bus.  Right now it's an ALL_PPC-only
option because it's actually needed for sound on some PReP boxes..

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

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[benh]

>We shouldn't be #ifdef'ing externs, since it doesn't matter.  The
>pmac/prep/chrp ones were hidden just because the line above was, iirc.
>
>And the one downside to the GENERIC_PPC32 platform_init, is that we're
>back to adding:
>#ifdef CONFIG_x
> case _MACH_x:
>  x_init(...);
>  break;
>#endif
>
>Which I think Paul was happy to see die :)

No, in the version I'm implementing for 2.5, the ppc_md structure of
each board will be statically defined and contain the init function.
A global array will contain ppc_md pointers indexed by machine.

Ben.


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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

On Mon, Apr 08, 2002 at 06:58:06PM +0100, benh@kernel.crashing.org wrote:
> >We shouldn't be #ifdef'ing externs, since it doesn't matter.  The
> >pmac/prep/chrp ones were hidden just because the line above was, iirc.
> >
> >And the one downside to the GENERIC_PPC32 platform_init, is that we're
> >back to adding:
> >#ifdef CONFIG_x
> > case _MACH_x:
> >  x_init(...);
> >  break;
> >#endif
> >
> >Which I think Paul was happy to see die :)
>
> No, in the version I'm implementing for 2.5, the ppc_md structure of
> each board will be statically defined and contain the init function.
> A global array will contain ppc_md pointers indexed by machine.

Won't that still lead to an:
#ifdef CONFIG_x
 ... set thingsup for CONFIG_X since this will only exist on CONFIG_x...
#endif

Or am I missing something?

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

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Benjamin Herrenschmidt]

>Won't that still lead to an:
>#ifdef CONFIG_x
> ... set thingsup for CONFIG_X since this will only exist on CONFIG_x...
>#endif
>
>Or am I missing something?

Yes, though it will be separated from the actual code, and I'm
thinking about eventually auto-generating it.

Ben.


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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Geert Uytterhoeven]

On Mon, 8 Apr 2002, Benjamin Herrenschmidt wrote:
> >Won't that still lead to an:
> >#ifdef CONFIG_x
> > ... set thingsup for CONFIG_X since this will only exist on CONFIG_x...
> >#endif
> >
> >Or am I missing something?
>
> Yes, though it will be separated from the actual code, and I'm
> thinking about eventually auto-generating it.

Or put the pointers to the ppc_md structs in a new section, cfr. the
module_init() stuff.

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: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[benh]

>
>> Yes, though it will be separated from the actual code, and I'm
>> thinking about eventually auto-generating it.
>
>Or put the pointers to the ppc_md structs in a new section, cfr. the
>module_init() stuff.
>

Right. That's the best solution for now. Though I may still do some
local code munging as I want to see how feasible it is to have _machine
be #defined instead of beeing a variable when only one board is selected
in the config, and without having to write a #ifdef mess in a .h for each
new board added.

Ben.

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[benh]

>
>And I'm hoping that some day PReP will be part of CONFIG_GENERIC_PPC32. See
>BenH's response about putting CONFIG_ALL_PPC to rest and converting to
>CONFIG_GENERIC_PPC32.

Yes, I've started doing that on a _devel code base, then figured out that
I had to cleanup a few crap remaining in pmac/chrp/prep, and that it would
rather be in 2.5 (we can still backport later).
So I'll start again on 2.5 this week but only for pmac/prep/chrp, I'll let
the various board maintainers decide wether to move their board under the
CONFIG_GENERIC_PPC32 umbrella or not.

Ben.


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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

On Mon, Apr 08, 2002 at 10:05:53AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > We shouldn't be #ifdef'ing externs, since it doesn't matter.  The
> > pmac/prep/chrp ones were hidden just because the line above was, iirc.
>
> OK.
>
> > And the one downside to the GENERIC_PPC32 platform_init, is that we're
> > back to adding:
> > #ifdef CONFIG_x
> >  case _MACH_x:
> >   x_init(...);
> >   break;
> > #endif
>
> And what's wrong with that? It allows the user to make the kernel size vs.
> generality trade-off: you can have one machine supported or all of them.

Well, take a look at what the file used to look like in _devel.  It was
around 30-40 lines of that.  Which is not nice to look at.

> > Which I think Paul was happy to see die :)
>
> But it's necessary, and it's a much better system than what you have now.

Well, it's a much better system if you want to group unlike hardware
together in one kernel. :)

> > >   arch/ppc/config.in
> > >     1.127 02/03/31 23:58:43 msokolov@helium.harhan.org +18 -21
> > >     Add generic PPC32 config, implemented for
> > >     Adirondack, EV-64260A, and K2
> >
> > Do any of these boards actually have an ISA slot?
>
> The boards I've used for this first implementation don't. But
> CONFIG_GENERIC_PPC32 is generic PPC32, not just these boards, and it should be
> possible for someone to support a machine with ISA slots under this generic
> framework.

Well, if ISA slots exist on the board, and should be working, they
should just work.  And when BenH merges in prep/chrp, it'll be needed.
But the question is do you really want to offer this up on machines
where it's not tested?

> > Right now it's an ALL_PPC-only
> > option because it's actually needed for sound on some PReP boxes..
>
> And I'm hoping that some day PReP will be part of CONFIG_GENERIC_PPC32. See
> BenH's response about putting CONFIG_ALL_PPC to rest and converting to
> CONFIG_GENERIC_PPC32.

Right.

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

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Well, take a look at what the file used to look like in _devel.  It was
> around 30-40 lines of that.  Which is not nice to look at.

So what's more important, a pretty look or better functionality for the user?

> Well, it's a much better system if you want to group unlike hardware
> together in one kernel. :)

Which is what I want to do, and which is the RTTD for distributions like
Debian.

> Well, if ISA slots exist on the board, and should be working, they
> should just work.  And when BenH merges in prep/chrp, it'll be needed.
> But the question is do you really want to offer this up on machines
> where it's not tested?

I want to have configurable CONFIG_PCI and CONFIG_ISA support for
CONFIG_GENERIC_PPC32. Generic means that things like this must be configurable.

MS

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

On Tue, Apr 09, 2002 at 12:23:57PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Well, take a look at what the file used to look like in _devel.  It was
> > around 30-40 lines of that.  Which is not nice to look at.
>
> So what's more important, a pretty look or better functionality for the user?
>
> > Well, it's a much better system if you want to group unlike hardware
> > together in one kernel. :)
>
> Which is what I want to do, and which is the RTTD for distributions like
> Debian.

Taking debian as an example here.  You certainly wouldn't stick a zImage
for every board into 1 package.  Why?  It'd be a 20mb package and as it
is a few people dislike the number of vmlinux's in the -pmac package.
So you only 'win' if you have a common, _bootable_ image on all of these
boards.   And while it is possible that there could be a common
firmware, I'm not holding my breath. :)

And the other point is that this makes it less clean to add in a new
board port.

> > Well, if ISA slots exist on the board, and should be working, they
> > should just work.  And when BenH merges in prep/chrp, it'll be needed.
> > But the question is do you really want to offer this up on machines
> > where it's not tested?
>
> I want to have configurable CONFIG_PCI and CONFIG_ISA support for
> CONFIG_GENERIC_PPC32. Generic means that things like this must be
> configurable.

But what if they aren't really configurable?  You could turn off
CONFIG_PCI, but I don't think you'd get too far on most[1] systems.

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

[1]: Most, not all, most.  I know there's 8xx and others...

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Taking debian as an example here.  You certainly wouldn't stick a zImage
> for every board into 1 package.

Exactly, which is why I never liked that idea.

> So you only 'win' if you have a common, _bootable_ image on all of these
> boards.

Yes.

> And while it is possible that there could be a common
> firmware, I'm not holding my breath. :)

When I go to Debian with this, I'll be asking for a ppcstar subarch to join to
the ranks of apus, chrp, powermac, and prep. All HEC PPC boards will be
PPCStar-compliant. If another manufacturer wants Debian support, they'll have
to address Debian themselves and decide for themselves if they want to
standardize their boot mechanism to make their request more acceptable.

> And the other point is that this makes it less clean to add in a new
> board port.

No, it's perfectly clean, you just throw one more machine into the
CONFIG_GENERIC_PPC32 framework.

> But what if they aren't really configurable?

They may not be configurable on a given board, but they are configurable given
an infinite number of boards.

> You could turn off
> CONFIG_PCI, but I don't think you'd get too far on most[1] systems.

Before I got fired from SBS I was getting ready to work on their new PPMC
boards which have GT-64260 instead of CPC700. While the old ones were only
practically usable as a monarch on a carrier board with useful PCI peripherals
like Ethernet, mass storage, etc. on the new ones they used GT-64260 Ethernets
and on-board IDE (flash disk) on the GT's device bus. This makes those boards
usable as independent computing engines in non-monarch mode where the PCI bus
doesn't belong to them and basically doesn't exist as far as they are
concerned. And those were normal 750CXe and 750FX boards, not 8xx or other very
very embedded stuff.

MS

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Daniel Jacobowitz]

On Tue, Apr 09, 2002 at 01:05:42PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Taking debian as an example here.  You certainly wouldn't stick a zImage
> > for every board into 1 package.
>
> Exactly, which is why I never liked that idea.
>
> > So you only 'win' if you have a common, _bootable_ image on all of these
> > boards.
>
> Yes.
>
> > And while it is possible that there could be a common
> > firmware, I'm not holding my breath. :)
>
> When I go to Debian with this, I'll be asking for a ppcstar subarch to join to
> the ranks of apus, chrp, powermac, and prep. All HEC PPC boards will be
> PPCStar-compliant. If another manufacturer wants Debian support, they'll have
> to address Debian themselves and decide for themselves if they want to
> standardize their boot mechanism to make their request more acceptable.

Debian only supplies CONFIG_ALL_PPC images right now.  The
CHRP/pmac/PREP breakdown was only for 2.2.

If GENERIC_PPC32 is adequate, I'll do that instead - when it's ready.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

On Tue, Apr 09, 2002 at 01:05:42PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > And the other point is that this makes it less clean to add in a new
> > board port.
>
> No, it's perfectly clean, you just throw one more machine into the
> CONFIG_GENERIC_PPC32 framework.

You're touching c files.  See Pauls comments about that.

> > But what if they aren't really configurable?
>
> They may not be configurable on a given board, but they are configurable given
> an infinite number of boards.

So why not ask it for boards where it's reasonable?  IE asking about
8xx enet on 6xx is harmless, but why do it?

> > You could turn off
> > CONFIG_PCI, but I don't think you'd get too far on most[1] systems.
>
[snip]

Yes, and I said most, not all, most. :)

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

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> So why not ask it for boards where it's reasonable?

So you mean replace the "$CONFIG_GENERIC_PPC32" = "y" condition with
"$CONFIG_BOARD_X" = "y" -o "$CONFIG_BOARD_Y" = "y" etc? Fine with me, but I
thought that was ugly code by your standards... :-)

MS

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Tom Rini]

On Wed, Apr 10, 2002 at 08:11:56PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > So why not ask it for boards where it's reasonable?
>
> So you mean replace the "$CONFIG_GENERIC_PPC32" = "y" condition with
> "$CONFIG_BOARD_X" = "y" -o "$CONFIG_BOARD_Y" = "y" etc? Fine with me, but I
> thought that was ugly code by your standards... :-)

Config files are where you're supposed to figure things out, not the C
files :)

Maybe someday we'll have some automagic bits in the config language
where we can specific sections and create all of the config questions on
the fly or something, but for now...

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

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

Re: Incoming to helium.harhan.org:/home/linuxppc/linuxppc_2_4_alt

[Troy Benjegerdes]

On Tue, Apr 09, 2002 at 12:23:57PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Well, take a look at what the file used to look like in _devel.  It was
> > around 30-40 lines of that.  Which is not nice to look at.
>
> So what's more important, a pretty look or better functionality for the user?

Above all, *readable* code, because otherwise someone changes something,
and inadvertently breaks machines that they don't have to test on.

Which then results in a crappy user experience because the same config
they are used to useing doesn't work anymore on the latest 'stable'
kernel.

This *still* happens a lot for my MTX, but it's gotten a lot better
over time.

If better functionality for the user is your goal, you can't achieve it by
designing code around that goal. (Unless, of course, you're Apple computer
and have large resources for QA and testing, and design the hardware
yourself)

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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