Re: PowerPC BOF at Ottawa Linux Symposium July 19

I won't be in Ottawa but I have a suggestion for something to talk about
there if anyone would be interested in it.  Could you have a brainstorming
session about how to re-structure the chip/architecture portions of
arch/ppc/?  I know there are several solutions out there for
arch/ppc/{chrp,prep,embedded,pmac} and arch/ppc/{4xx,6xx,8xx} but would
like to find a solution that fits everyones needs (or at least satisfies
several of them.

I'd like to start the work sometime in 2.5.

} I introduced the idea of a PowerPC Linux BOF on linuxppc-workstation
} and someone said I should also post it on linuxppc-dev.
} The idea is to have a meeting of people interested in PowerPC
} Linux on the first day (July 19) of the Ottawa Linux Symposium
} from 5-7PM eastern time.   This doesn't appear to conflict
} with any other meetings at the Symposium.
}
} There are some people who would like to attend a PowerPC
} Linux BOF, but will not be in Ottawa.   So I decided to get an
} 800 dial-in conference number for people to call in and talk/listen.
} I know how hard it is to hear on those things, but it will be helpful
} if people on the phone can do a 5 minute talk on the work they
} are doing with respect to PowerPC Linux and to share
} their concerns with everyone.     So if you are not going to
} Ottawa and want to join the PowerPC BOF, send me e-mail
} so I can send you the 800 number.   Also, if there is enough
} interest, I will get an international number for Europe.   Although
} it will be pretty late for Europe.   You should also e-mail me
} if you are going to Ottawa in person so I can buy enough pizza
} and beverages.
}
} I have asked the symposium organizers if a BOF at 5-7pm on the
} first day (July 19) is OK and I have not heard anything back yet.
} I will wait for some response and if OK,  I will reserve a room at the
} Conference Centre with a conference phone.
}
} Please send me ideas for what people would like to cover at
} the meeting.  I was hoping to create a top10 list of tactical and
} strategic work items for PowerPC Linux.    For example one item
} might be the port of QuickTime Player to Linux PPC.   If this
} meeting is successful, we can review these lists every year.
} I will be glad to serve as secretary and post them on these
} news groups.
}
} You may ask, "who am I to be organizing this?"  This is probably
} the first time you've seen my name.   I have been quietly listening
} to linuxppc-dev and linuxppc-workstation for about a year.
} My interest is running Linux on high-end PowerPC servers.
} I know we will never get there without all the work that was done
} for the Mac and other PowerPC platforms.    I am still getting up
} to speed technically, but I do bring some organizational skills.
} I recently lead a team of people to port Linux to the POWER4
} microprocessor.    Paul Mackerras and Tom Gall were on that
} team.   These names should be more familiar to people on this
} news group.
}
} If anyone else wants to help organize this meeting,
} please let me know.   The more the better.
}
} Have fun!
}
} Greg Rodgers (rodgersg@us.ibm.com)
} 914-892-1319  Tie 532-1319

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

Cort Dougan wrote:

I won't be in Ottawa but I have a suggestion for something to talk about
there if anyone would be interested in it.  Could you have a brainstorming
session about how to re-structure the chip/architecture portions of
arch/ppc/?

I don't know if I will be there, but I would like to make a comment
on this as well.  The BOF started as a workstation/server discussion,
and the chip/architecture issues are really the result of the variety
of embedded PowerPC processors and boards.

There is PREP/CHRP/PowerMac that you have successfully combined, with
minor configuration differences among all of them.  Then we have lots
of different PowerPC cores with highly integrated functional units on
a variety of different board configurations.  I think we are fortunate
to be able to provide this wide range of solutions, but it does present
the source code structure challenge as Cort (and others) have discussed.

As a workstation/server BOF, I don't know how much interest exists to
discuss this.  The easy answer is a set of orthogonal directory trees,
but I think the highest priority should be on maintaining a set of
common files.  Having experienced splitting some processor dependent
files, I would still take the #ifdefs over tracking similar changes
across multiple files.


	-- Dan

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

Dan Malek wrote:

As a workstation/server BOF, I don't know how much interest exists to
discuss this.  The easy answer is a set of orthogonal directory trees,
but I think the highest priority should be on maintaining a set of
common files.  Having experienced splitting some processor dependent
files, I would still take the #ifdefs over tracking similar changes
across multiple files.

I'd go with that some of the way, but I think MMU_init() in mm/init.c
goes a bit too far. It feels like every time I port my patches to a new
release kernel somebody has added extra boards and I have to sort switch
statements out by hand.

As an example, looking at 2.2 and 2.3, the actions performed by
xxx_find_end_of_memory() haven't changed very much. There probably
wouldn't be much problem introducing a ppc_md.find_end_of_memory call(),
and patches to add new machines would apply much cleaner.

I don't think the world is ready for my dream of eliminating _machine
completely, but if there's any interest I can attempt a test refactoring
of mm/init.c. This needn't be an all at once change; the idiom I'm
thinking of goes something like:
	if (ppc_md.do_whatever())
		ppc_md.do_whatever();
	else {
#ifndef CONFIG_8xx
	switch(_machine)
	...
#else
	8xx_do_whatever();
#endif
	}

- Adrian Cox, AG Electronics

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