Restructuring Efforts

Restructuring Efforts

[Christian Zankel]

Hello,

> > [ some sentences about porting LinuxPPC to Force CPCI 750 board ]

> It depends on what the board provides, some residual data, an OF like
> device tree or nothing (worst case since interrupt routing may be the [...]

Actually, the Force PowerCore 6750 has nothing (or almost nothing). I've
just started with the port, but ran
into some difficulties: There seems to be a lot of dependencies between
different machines (ie. pmac, prep, chrp, mbx, etc.), I didn't want to
pay attention to. (E.g. I do not need PMac's keyboard and SCSI driver,
which seems to be compiled in per default. Especially, I do not need any
calls to read the OF tree, residual data, etc.)

> Restructuring efforts have been announced and some patches are floating
> around.

I've seen that you have setup a directory for those patches. But
couldn't you start with a seperate cvs tree to move the process of
restructuring the kernel forward? I mean, having a kind of 'official'
inofficial LinuxPPC developer kernel. I'd also really appreciate it if
there could be a kind of a statement(?) and perhaps a short discussion
about the restructured arch/ppc tree. I'd like to ask especially you,
Cort, as you seem to be the maintainer of the LinuxPPC port, how you see
the restructured arch/ppc tree. I'd like to help, but need to know where
arch/ppc is going to be. 

I hope that a little discussion is allowed here:
(Please, understand that my point of view is from a board where the
initialization is different from those with an OF)

1. Directory Structure
It seems that efforts are going to create one 'super' PPC-kernel
suitable for all the PPC machines.
I can't say that I'm really happy about it. I think there might be more
overhead, unreadibility (i.e. a lot #ifdef's), bigger kernels, etc. I'd
like to see the Macintosh, PreP, CHRP, etc. more seperated, ie. in
different directories (one for pmac, prep, chrp, apus, mbx, pcore6750,
etc.) I think, it's then much easier to add new machines, new PPC
generations, etc. Short: I don't think is wise to have only one
CONFIG_PMAC_PREP_CHRP_?_? for all machines and let the kernel decide at
boot time what to do. Do I overlook here something?

2. kernel/head.S
It seems that the basic initialization varies from board to board.
Porting LinuxPPC to the Force board would result in more #ifdef's. I'd
suggest to seperate the 'exceptions' part (into trap.S) from the
initialization code and put the later one into the mach-dirs.

3. OF
The Force board has no OF and no residual structures. What I have in
mind is to replace the firmware of the board completely with a MILO-like
firmware. This firmware should be able to boot an elf-vmlinux image
either from the same flash, or the user-flash, from network, or scsi.
Would it possible to seperate the calls to read data from OF and to read
residual data, from the generic sources (especially in arch/ppc/mm) ? 

These are some questions I ran into porting LinuxPPC to the Force board.
Mainly, I do not understand why those three machines, PowerMac
(PPC601-PPC750), CHRP and PReP are put so closely together. For me, it
seems that a lot of #ifdef's, switch(es) and branches are necessary to
achieve this. Perhaps someone can point me in the right direction here.


Thanks,
Christian

-- 
Christian Zankel       <zankel@mailserv.rz.fh-muenchen.de>

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Cort Dougan]

I want to avoid another tree.  It'll create chaos.  It'll also make my job
a lot harder.  Things do need to move slowly for a while.  The ppc tree
could get ugly really quickly by adding all the new archs.  We already have
more than any other port and will be getting more soon.  I want this to
serve as motivation for a slow (by linux standards) and careful redesign
rather than a hack to get arch X, Y and Z working now.

The first step is underway.  I want to cleanup the bootloader mess for
prep/yellowknife/mbx/rpx.  Moving the embedded stuff to arch/ppc/mbxboot
will cleanup the prep stuff a good deal.  Then I'll go through the prep
stuff and most likely replace it with Gabriels bootloader for prep.  It's a
small step but it needs to be done and it'll move us ahead.

Keep in mind the 2.2 tree is supposed to be stable.  As few changes as
possible and only to fix things.  I think the restructure is important
enough to work on now, though.

This is why I have the directory at linuxppc.cs.nmt.edu for patches.  I'd
like to collect the patches so we can all look through one anothers work.
I'd like things to bounce around a bit before going into the tree.  I think
we should use the -dev list for that. There are several different ideas out
there for the restructure and I'd like to go through them pretty thoroughly
before adopting one or any combination of them.

}I've seen that you have setup a directory for those patches. But
}couldn't you start with a seperate cvs tree to move the process of
}restructuring the kernel forward? I mean, having a kind of 'official'
}inofficial LinuxPPC developer kernel. I'd also really appreciate it if
}there could be a kind of a statement(?) and perhaps a short discussion
}about the restructured arch/ppc tree. I'd like to ask especially you,
}Cort, as you seem to be the maintainer of the LinuxPPC port, how you see
}the restructured arch/ppc tree. I'd like to help, but need to know where
}arch/ppc is going to be. 

I'd like the end result to be something that allows you to apply patches
for your board without much trouble from version to version.  Things with
limited use (your board?) shouldn't go into the kernel.  It'll complicate
things too much I think.  That doesn't preclude the main tree from making
it an easy job for you to apply your changes.  Trying to do everything
right off could make a big mess of things.

As always, I'm willing to change my mind but I want a general consensus
from the community before I do.

}I hope that a little discussion is allowed here:
}(Please, understand that my point of view is from a board where the
}initialization is different from those with an OF)

Not quite.  Just chrp/prep/pmac (and soon apus I hope).  I want a single
kernel for the desktop to avoid recompiles when testing out kernels.  Ram
isn't a big deal on these machines (a few K for a generic kernel isn't a
big deal anyway).  The performance loss is negligible as well (it can be
improved though).  Other boards (especially embedded) can't do this - it
would be insane :)  Those will be compiled specifically for the target
architecture.

}It seems that efforts are going to create one 'super' PPC-kernel
}suitable for all the PPC machines.

Those #ifdefs are really hard to work with - the single kernel avoids many
of them.  It takes a lot of work to move in even one small patch if I have
to recompile for each architecture and track down bugs.  Too many code
paths are dangerous.

}I can't say that I'm really happy about it. I think there might be more
}overhead, unreadibility (i.e. a lot #ifdef's), bigger kernels, etc. I'd

Take a tour through the code looking for places that can be done.  I still
think things can be merged with careful thought.  There's quite a bit of
common code (pmac/prep/chrp/apus wise anyway).  If you can find some
specific places you don't think this isn't the case point them out to me.

}like to see the Macintosh, PreP, CHRP, etc. more seperated, ie. in
}different directories (one for pmac, prep, chrp, apus, mbx, pcore6750,
}etc.) I think, it's then much easier to add new machines, new PPC
}generations, etc. Short: I don't think is wise to have only one
}CONFIG_PMAC_PREP_CHRP_?_? for all machines and let the kernel decide at
}boot time what to do. Do I overlook here something?

I think this will happen.  The 8xx series is really different from the
6xx/7xx and the 4xx/5xx are as well.

}2. kernel/head.S
}It seems that the basic initialization varies from board to board.
}Porting LinuxPPC to the Force board would result in more #ifdef's. I'd
}suggest to seperate the 'exceptions' part (into trap.S) from the
}initialization code and put the later one into the mach-dirs.

They're init sections so they get dropped after boot.  There is some of
code that gets freed after boot on machines that don't need it.  We can
make that conditional upon have_of.

}The Force board has no OF and no residual structures. What I have in
}mind is to replace the firmware of the board completely with a MILO-like
}firmware. This firmware should be able to boot an elf-vmlinux image
}either from the same flash, or the user-flash, from network, or scsi.
}Would it possible to seperate the calls to read data from OF and to read
}residual data, from the generic sources (especially in arch/ppc/mm) ? 

I want to get rid of ifdefs.  When creating the generic desktop kernel the
comparisons in the 'if' (not ifdef) are done.  When compiling for a
specific arch the _machine value is no longer a variable but a constant.
The compile optimizes out the 'if' and gives you a straight path.

}These are some questions I ran into porting LinuxPPC to the Force board.
}Mainly, I do not understand why those three machines, PowerMac
}(PPC601-PPC750), CHRP and PReP are put so closely together. For me, it
}seems that a lot of #ifdef's, switch(es) and branches are necessary to
}achieve this. Perhaps someone can point me in the right direction here.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Troy Benjegerdes]

On Tue, 16 Feb 1999, Cort Dougan wrote:

> 
> I want to avoid another tree.  It'll create chaos.  It'll also make my job
> a lot harder.  Things do need to move slowly for a while.  The ppc tree
> could get ugly really quickly by adding all the new archs.  We already have
> more than any other port and will be getting more soon.  I want this to
> serve as motivation for a slow (by linux standards) and careful redesign
> rather than a hack to get arch X, Y and Z working now.
> 
I would argue that after the careful redesign has been done, a second tree
would be a good idea. As it is now, it seem to me that there are a large
bunch of incompatible chaotic patches floating around. If there were
another CVS archive with the new redesign, you could slowly merge things
into the mainline kernel, while the rest of us that need all these new
bleeding edge arches can have a central place where everything is kept, in
a format easy to get at. (patches are really a pain in the ass.. I started
keeping a local CVS repository for this very reason)

> The first step is underway.  I want to cleanup the bootloader mess for
> prep/yellowknife/mbx/rpx.  Moving the embedded stuff to arch/ppc/mbxboot
> will cleanup the prep stuff a good deal.  Then I'll go through the prep
> stuff and most likely replace it with Gabriels bootloader for prep.  It's a
> small step but it needs to be done and it'll move us ahead.
> 
> Keep in mind the 2.2 tree is supposed to be stable.  As few changes as
> possible and only to fix things.  I think the restructure is important
> enough to work on now, though.
> 
Another reason (IMO) to have a separate tree.. As soon as an official 2.3
is out, we can dump a large set of working patches directly into it from
the redone PPC-rework tree.

> This is why I have the directory at linuxppc.cs.nmt.edu for patches.  I'd
> like to collect the patches so we can all look through one anothers work.
> I'd like things to bounce around a bit before going into the tree.  I think
> we should use the -dev list for that. There are several different ideas out
> there for the restructure and I'd like to go through them pretty thoroughly
> before adopting one or any combination of them.
> 
I'm somewhat partial to the work Corey Minyard started (since I'm using it
for the MTX SMP support). I think it would help for anyone interested to
take a look at the way Alpha handles different architectures.

[snip]

> I want to get rid of ifdefs.  When creating the generic desktop kernel the
> comparisons in the 'if' (not ifdef) are done.  When compiling for a
> specific arch the _machine value is no longer a variable but a constant.
> The compile optimizes out the 'if' and gives you a straight path.
> 

ifdefs are evil ;) 
OTOH, I don't know if I like a ton of 'if _machine' from a readability
standpoint. I would like something similiar to the Alpha's and Corey
Minyards rework with a structure for various machines with any code that
would have been inside an #ifdef , switch(_machine) if _machine. 

Then, any generic kernel lookups take one memory access to find the
function (if we, or the compiler can keep the structure pointer in a
register), and hopefully the structure can be cache-aligned so that it
sits in a couple of L2 or L1 cache lines when in kernel mode.

For a specfic machine config, the structure members could be #defined to
be the actuall function, giveing a straight function call.

This also makes MTX support a lot easier, since I ended up haveing the
structure point to half of the CHRP functions and half of the PReP
functions.

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Cort Dougan]

I was thinking about that over the last few hours.  The cvs repository for
ppc could work.  I'd be happy to set one up and maintain the cvs tree
for ppc but I have a few problems with it.  1) I would have to move things
from our tree to vger then to linus.  I think testing things in vger is
pretty important since we get to find problems with other peoples code
coming in before it goes to Linus' tree - we can work on it there quickly
to solve the early problems.  2) The changes could come in way too
quickly.  We have incompatible patches out there now, but how would it be
having incompatible changes going into the linux/ppc cvs tree?  We'd have
a broken starting point rather than a working and reasonably stable one.
Bitkeeper might help here, but in essence it just ships patches (Larry
calls 'em deltas) around via smtp.

With metered (and well behaved :) changes going into a linux/ppc cvs tree
I think that wouldn't be a problem.  So I can get a handle on the scope of
things, how many people would want r/w access to a linux/ppc cvs tree?

I believe the number of patches floating around that can go into the
main kernel are in the single digits.  There's quite a bit of overlap in
them I'm pretty sure.  I see the patches as a system for fleshing out
problems before I move them into vger. 

}I would argue that after the careful redesign has been done, a second tree
}would be a good idea. As it is now, it seem to me that there are a large
}bunch of incompatible chaotic patches floating around. If there were
}another CVS archive with the new redesign, you could slowly merge things
}into the mainline kernel, while the rest of us that need all these new

We can do that with vger.  There's no reason vger has to be the same as
Linus'.  That is, the ppc specific parts of the tree only.

}Another reason (IMO) to have a separate tree.. As soon as an official 2.3
}is out, we can dump a large set of working patches directly into it from
}the redone PPC-rework tree.

That's coming up next.

}I'm somewhat partial to the work Corey Minyard started (since I'm using it
}for the MTX SMP support). I think it would help for anyone interested to
}take a look at the way Alpha handles different architectures.

GCC must be the personification of sin itself :)

}ifdefs are evil ;) 

(if _machine) was a euphemism for switch(_machine) which is cleaner than
#ifdef.

}OTOH, I don't know if I like a ton of 'if _machine' from a readability
}standpoint. I would like something similiar to the Alpha's and Corey
}Minyards rework with a structure for various machines with any code that
}would have been inside an #ifdef , switch(_machine) if _machine. 

Similar to what I was aiming at with the pci config access stuff and got
closer to with the current irq.c, right?  I'm trying to do the shaking of
all the patches for restructing to see what comes out.  Corey's work (along
with others) does look good.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Gabriel Paubert]

On Tue, 16 Feb 1999, Cort Dougan wrote:

> I was thinking about that over the last few hours.  The cvs repository for
> ppc could work.  I'd be happy to set one up and maintain the cvs tree
> for ppc but I have a few problems with it.  1) I would have to move things
> from our tree to vger then to linus.  I think testing things in vger is
> pretty important since we get to find problems with other peoples code
> coming in before it goes to Linus' tree - we can work on it there quickly
> to solve the early problems.  2) The changes could come in way too
> quickly.  We have incompatible patches out there now, but how would it be
> having incompatible changes going into the linux/ppc cvs tree?  We'd have
> a broken starting point rather than a working and reasonably stable one.
> Bitkeeper might help here, but in essence it just ships patches (Larry
> calls 'em deltas) around via smtp.
> 
> With metered (and well behaved :) changes going into a linux/ppc cvs tree
> I think that wouldn't be a problem.  So I can get a handle on the scope of
> things, how many people would want r/w access to a linux/ppc cvs tree?

I never wanted r/w access to vger, but I would probably ask for one on a
PPC specific tree.  But I don't see why changes specific to arch/ppc have
to go to vger first, at least in a development tree which is supposed to
break occasionally (and vger was regularly merged with Linus'patches). Do
not forget that with the long list of mirrors of Linus'tree, these kernels
get a much larger public exposure. 

> I believe the number of patches floating around that can go into the
> main kernel are in the single digits.  There's quite a bit of overlap in
> them I'm pretty sure.  I see the patches as a system for fleshing out
> problems before I move them into vger. 

No problem with this. 

> We can do that with vger.  There's no reason vger has to be the same as
> Linus'.  That is, the ppc specific parts of the tree only.

But who has access to vger lately ? I have been bitten very hard and
switched back to Linus'tree because of this. I spent too much time in the
switch, having to check around 600 files (ok, it made me very familiar
with emacs ediff modes ;-)) and I don't want it to happen again.

Besides this, the mirrors in Europe make it easy for me to keep up to date
with Linus's tree, while I couldn't keep up with vger. My effective
bandwidth to the US is awful: who can say that surfing the web at any
speed higher than 20 bytes/second is an exhilarating experience ? 

(Yes I mean twenty bytes per second or 160 baud, I've not forgotten any
kilo/mega/gigha/tera/peta/exa prefix, wherever I have travelled in the
last 3 years, the worst case was at least an order of magnitude faster
than from here).

> Similar to what I was aiming at with the pci config access stuff and got
> closer to with the current irq.c, right?  I'm trying to do the shaking of
> all the patches for restructing to see what comes out.  Corey's work (along
> with others) does look good.

I'm currently running a kernel with Corey+Troy+prepboot+ a few patches of
mine. I'm going to upload the patch soon, once I split it into 3 parts
(prepboot+vme+rest, vme is being completely restructured so it won't be
there). 

	Gabriel


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Troy Benjegerdes]

I propose that since a release of Bitkeeper is supposedly imminent, that
we attempt to make use of it for the PPC specific tree. This should be
closer to the 'patch' idea Cort wanted in the first place, and will most
definitely make things easier for Gabriel with his poor trans-atlantic
connection ;)

According to the bitkeeper mail list, there will most likely be a bunch of
bitkeeper mirrors of the official kernel, which would make it quite easy
for Gabriel to grab new updates to the new kernel and automatically
merge in the PPC devel changes.

On Wed, 17 Feb 1999, Gabriel Paubert wrote:

> On Tue, 16 Feb 1999, Cort Dougan wrote:
> 
> > I was thinking about that over the last few hours.  The cvs repository for
> > ppc could work.  I'd be happy to set one up and maintain the cvs tree
> > for ppc but I have a few problems with it.  1) I would have to move things
> > from our tree to vger then to linus.  I think testing things in vger is
> > pretty important since we get to find problems with other peoples code
> > coming in before it goes to Linus' tree - we can work on it there quickly
> > to solve the early problems.  2) The changes could come in way too
> > quickly.  We have incompatible patches out there now, but how would it be
> > having incompatible changes going into the linux/ppc cvs tree?  We'd have
> > a broken starting point rather than a working and reasonably stable one.
> > Bitkeeper might help here, but in essence it just ships patches (Larry
> > calls 'em deltas) around via smtp.
> > 
> > With metered (and well behaved :) changes going into a linux/ppc cvs tree
> > I think that wouldn't be a problem.  So I can get a handle on the scope of
> > things, how many people would want r/w access to a linux/ppc cvs tree?
> 
[snip]

> But who has access to vger lately ? I have been bitten very hard and
> switched back to Linus'tree because of this. I spent too much time in the
> switch, having to check around 600 files (ok, it made me very familiar
> with emacs ediff modes ;-)) and I don't want it to happen again.
> 
> Besides this, the mirrors in Europe make it easy for me to keep up to date
> with Linus's tree, while I couldn't keep up with vger. My effective
> bandwidth to the US is awful: who can say that surfing the web at any
> speed higher than 20 bytes/second is an exhilarating experience ? 
> 
> (Yes I mean twenty bytes per second or 160 baud, I've not forgotten any
> kilo/mega/gigha/tera/peta/exa prefix, wherever I have travelled in the
> last 3 years, the worst case was at least an order of magnitude faster
> than from here).
> 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Benjamin Herrenschmidt]

On Tue, Feb 16, 1999, Cort Dougan <cort@persephone.cs.nmt.edu> wrote:

>With metered (and well behaved :) changes going into a linux/ppc cvs tree
>I think that wouldn't be a problem.  So I can get a handle on the scope of
>things, how many people would want r/w access to a linux/ppc cvs tree?

I would prefer that rather than one on vger. Many parts of Linux are
still really obscure to me and I'm really afraid of breaking things. I
prefer having to deal with two trees: an "official" one with qualified
patches than can be tested by users and that will ultimately go to Linus,
and a "developement" tree containing more cutting-edge stuffs.

However, the problem that will quickly come from that is the difficulty
to merge changes from the dev tree to vger, at least until 2.3.x is split.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [ppc-dev] Re: Restructuring Efforts

[Bill Davidsen]

Troy Benjegerdes <hozer@drgw.net> noted:

> ifdefs are evil ;) 
> OTOH, I don't know if I like a ton of 'if _machine' from a readability
> standpoint. I would like something similiar to the Alpha's and Corey
> Minyards rework with a structure for various machines with any code that
> would have been inside an #ifdef , switch(_machine) if _machine. 

Well, you can preserve readability if you are willing to put the
machine types in an enum and make use of "pointer to function
returning" arrays. So instead of doing something like init_mem() you
would use (*init_mem[_machine])() instead.

Another trick is to have a set if defines which you provide for each
machine type, and then call. Either of these provide easy extensibility
without ifdefs.

-- 
   -bill davidsen (davidsen@prodigy.com)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [ppc-dev] Re: Restructuring Efforts

[Benjamin Herrenschmidt]

On Wed, Feb 17, 1999, Bill Davidsen <davidsen@prodigy.com> wrote:

>Well, you can preserve readability if you are willing to put the
>machine types in an enum and make use of "pointer to function
>returning" arrays. So instead of doing something like init_mem() you
>would use (*init_mem[_machine])() instead.

What we are trying to do here is a HAL ;-) 

I like the function pointers idea but I don't like indexing by machines
each time the table is accessed. I beleive we should define a structure
of function pointers for each subsystem (setup, mm, irq, ...) at have
some boot logic fill the kernel static tables with pointers from the
subsystem exported tables. The decision based on the architecure must be
done only once.

Eventually, those tables could be "optimised" so that they are all in the
same page, each table beeing aligned on a cache line boundary.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [ppc-dev] Re: Restructuring Efforts

[David A. Gatwood]

On Wed, 17 Feb 1999, Benjamin Herrenschmidt wrote:

> I like the function pointers idea but I don't like indexing by machines
> each time the table is accessed. I beleive we should define a structure
> of function pointers for each subsystem (setup, mm, irq, ...) at have
> some boot logic fill the kernel static tables with pointers from the
> subsystem exported tables. The decision based on the architecure must be
> done only once.

Sounds a lot like a bunch of things in BSD-like kernels, where, in
MkLinux, for instance, interrupt_heathrow.c, interrupt_pdm.c, etc. each
have a static structure with pointers to their externally visible
functions, and the main function checks the hardware type and assigns a
global pointer to point to the static structure for the particular set of
routines.  Is that what you mean?


Later,
David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [ppc-dev] Re: Restructuring Efforts

[Benjamin Herrenschmidt]

On Wed, Feb 17, 1999, David A. Gatwood <marsmail@globegate.utm.edu> wrote:

>Sounds a lot like a bunch of things in BSD-like kernels, where, in
>MkLinux, for instance, interrupt_heathrow.c, interrupt_pdm.c, etc. each
>have a static structure with pointers to their externally visible
>functions, and the main function checks the hardware type and assigns a
>global pointer to point to the static structure for the particular set of
>routines.  Is that what you mean?

Almost ;-)

This scheme still requires one more pointer dereferencing: one to get to
the global holding the structure pointer, one to get the structure, one
to get the function.

I was thinking about filling a static structure with function pointers
instead (but the "modules" can still export a pointer to a structure, the
kernel will just copy the pointers in the structure instead of just
storing a pointer to the structure).
This way, we have one less indirection.
If the structure can be stored at a fixed address in kernel virtual space
(hummm....) then access to the function pointers can be really fast.

Of course, this is really a matter of details, but since those will be
used in a lot of performance sensitive execution path (interrupts, mm,
...), such optimisation can make a difference by avoiding unnecessary
cache misses.

Maybe we could wrap the calls to the functions themselves in macros so
that we can later change the way the mecanism is implemented.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Gabriel Paubert]

On Tue, 16 Feb 1999, Cort Dougan wrote:

> Not quite.  Just chrp/prep/pmac (and soon apus I hope).  I want a single
> kernel for the desktop to avoid recompiles when testing out kernels.  Ram
> isn't a big deal on these machines (a few K for a generic kernel isn't a
> big deal anyway).  The performance loss is negligible as well (it can be
> improved though).  Other boards (especially embedded) can't do this - it
> would be insane :)  Those will be compiled specifically for the target
> architecture.

I had the impression that the APUS I/O accesses had to use non byte
swapped instruction, so that merging the APUS with the other would be
hard. Is there something I missed ? 

I don't want the kernel to execute conditional code or to call a
subroutine for every I/O access, this is bloat and/or inefficiency for
the sake of it. 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Jesper Skov]

>>>>> "Gabriel" == Gabriel Paubert <paubert@iram.es> writes:
Gabriel> I had the impression that the APUS I/O accesses had to use
Gabriel> non byte swapped instruction, so that merging the APUS with
Gabriel> the other would be hard. Is there something I missed ?

True, APUS doesn't require byte swapping. But I don't see how this
makes it hard to integrate APUS.

Gabriel> I don't want the kernel to execute conditional code or to
Gabriel> call a subroutine for every I/O access, this is bloat and/or
Gabriel> inefficiency for the sake of it.


This is a valid concern. I don't know if it's possible to do anything
about this. 

It may be the case that none of the Amiga drivers use the same IO
macros as other drivers use. As I remember it, there are two set of
macros. But it's a long time since I looked at that, I could be wrong.

Jesper

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Gabriel Paubert]

On 18 Feb 1999, Jesper Skov wrote:

> >>>>> "Gabriel" == Gabriel Paubert <paubert@iram.es> writes:
> Gabriel> I had the impression that the APUS I/O accesses had to use
> Gabriel> non byte swapped instruction, so that merging the APUS with
> Gabriel> the other would be hard. Is there something I missed ?
> 
> True, APUS doesn't require byte swapping. But I don't see how this
> makes it hard to integrate APUS.

It means that you can't run the same kernel image, it would require
deciding between a byte swapping and non-byte swapping instruction on each
and every in[wl] and out[wl] instruction. It is possible to build a
CHRP/PreP/Pmac kernel and then only select the right drivers, but I can't
see how you can merge CONFIG_APUS in it without a huge performance and/or
size penalty (and do it in an acceptably clean way, I have some ideas
about dirty trick solutions).

> Gabriel> I don't want the kernel to execute conditional code or to
> Gabriel> call a subroutine for every I/O access, this is bloat and/or
> Gabriel> inefficiency for the sake of it.
> 
> This is a valid concern. I don't know if it's possible to do anything
> about this. 
> 
> It may be the case that none of the Amiga drivers use the same IO
> macros as other drivers use. As I remember it, there are two set of
> macros. But it's a long time since I looked at that, I could be wrong.

No they don't, have a look at include/asm-ppc/io.h, there is a lot of
ifdef on CONFIG_APUS. This can't reasonably be made into a run time
option IMHO.

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Jesper Skov]

>>>>> "Gabriel" == Gabriel Paubert <paubert@iram.es> writes:

>>  This is a valid concern. I don't know if it's possible to do
>> anything about this.
>> 
>> It may be the case that none of the Amiga drivers use the same IO
>> macros as other drivers use. As I remember it, there are two set of
>> macros. But it's a long time since I looked at that, I could be
>> wrong.

Gabriel> No they don't, have a look at include/asm-ppc/io.h, there is
Gabriel> a lot of ifdef on CONFIG_APUS. This can't reasonably be made
Gabriel> into a run time option IMHO.

I'm aware of having made those changes :)   What I'm not sure about is
whether I experienced problems with both read/writex and in/outx, or
just did the conversion wholesale. 

What I'm considering is whether it would be possible to use the _ns
variants in Amiga drivers -- which is quite likely. Then you could
swap bytes to your heart's content in the other macros for all I care.

Jesoer

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Cort Dougan]

I was just trying this out with tlbia: Use real tlbias in the kernel even
on chips that don't do tlbia.  When on a chip that doesn't have the tlbia
instruction take the trap and fix the code up in the trap handler (put in
a bl soft_tlbia instead of a tlbia).  We could do something like this per
architecture.  When doing an arch specific function trap, take the trap
and fix it up.  The problem with that is keeping track of the myriad of
functions we need to keep track of.

}It may be the case that none of the Amiga drivers use the same IO
}macros as other drivers use. As I remember it, there are two set of
}macros. But it's a long time since I looked at that, I could be wrong.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Troy Benjegerdes]

Now that's kinda slick.. (And sorta scary ;)

> 
> I was just trying this out with tlbia: Use real tlbias in the kernel even
> on chips that don't do tlbia.  When on a chip that doesn't have the tlbia
> instruction take the trap and fix the code up in the trap handler (put in
> a bl soft_tlbia instead of a tlbia).  We could do something like this per
> architecture.  When doing an arch specific function trap, take the trap
> and fix it up.  The problem with that is keeping track of the myriad of
> functions we need to keep track of.
> 
> }It may be the case that none of the Amiga drivers use the same IO
> }macros as other drivers use. As I remember it, there are two set of
> }macros. But it's a long time since I looked at that, I could be wrong.
> 
> 
> 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Gabriel Paubert]

On Thu, 18 Feb 1999, Cort Dougan wrote:

> 
> I was just trying this out with tlbia: Use real tlbias in the kernel even
> on chips that don't do tlbia.  When on a chip that doesn't have the tlbia
> instruction take the trap and fix the code up in the trap handler (put in
> a bl soft_tlbia instead of a tlbia).  We could do something like this per
> architecture.  When doing an arch specific function trap, take the trap
> and fix it up.  The problem with that is keeping track of the myriad of
> functions we need to keep track of.

I was thinking along different lines: add a linker section called
.apus_fixups or so in which I would keep the addresses of all the
in[wl]/out[wl] instructions and patch very early in the boot
according to the following rules: 

	lhbrx  -> lhzx
	lwbrx  -> lwzx
	sthbrx -> sthx
	stwbrx -> stwbrx

between these pairs of instructions only the extended part of the opcode
is different, it would not work the other way around since non byte
swapping instructions have more addressing modes. I once asked on an egcs
list if it would be possible to add a constraint for "x" addressing mode
only because it would make some things simpler (and Altivec only has this
addressing mode): the answer was no, unfortunately. 
    
Of course this section would be freed up and the space reclaimed. The
macros would not be much more complex than they are now: 

asm("1: 	lhbrx %0,0,%1;\t"
	"	.section .apus_fixups,ar;\t"
	"	.long 1b;\t"
	"	.previous"
 

Same idea could perhaps be applied for tlbia to avoid adding runtime
exception handler code and overhead.

	Regards,
	Gabriel.  


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: [ppc-dev] Re: Restructuring Efforts

[Bill Davidsen]

> Keep in mind the 2.2 tree is supposed to be stable.  As few changes as
> possible and only to fix things.  I think the restructure is important
> enough to work on now, though.

Maybe work should be moved to the 2.3 tree when it emerges.

> I'd like the end result to be something that allows you to apply patches
> for your board without much trouble from version to version.  Things with
> limited use (your board?) shouldn't go into the kernel.  It'll complicate
> things too much I think.  That doesn't preclude the main tree from making
> it an easy job for you to apply your changes.  Trying to do everything
> right off could make a big mess of things.

This seems to indicate the desirability of using directories rather than
putting everything inline with ifdefs. It allows someone to support a
small production board by dropping in their own directory and pointing
the symbolic link. It also makes it easier to apply patches, since it's
obvious if a change is generic or related to a single board (or board
family).

> As always, I'm willing to change my mind but I want a general consensus
> from the community before I do.
> 
> }I hope that a little discussion is allowed here:
> }(Please, understand that my point of view is from a board where the
> }initialization is different from those with an OF)
> 
> Not quite.  Just chrp/prep/pmac (and soon apus I hope).  I want a single
> kernel for the desktop to avoid recompiles when testing out kernels.  Ram
> isn't a big deal on these machines (a few K for a generic kernel isn't a
> big deal anyway).  The performance loss is negligible as well (it can be
> improved though).  Other boards (especially embedded) can't do this - it
> would be insane :)  Those will be compiled specifically for the target
> architecture.

But it would be desirable to have the "all purpose" init also in a dir
of its own, rather than ifdef it out. Or so it seems to me.

> }It seems that efforts are going to create one 'super' PPC-kernel
> }suitable for all the PPC machines.
> 
> Those #ifdefs are really hard to work with - the single kernel avoids many
> of them.  It takes a lot of work to move in even one small patch if I have
> to recompile for each architecture and track down bugs.  Too many code
> paths are dangerous.

See above on this, I agree that it can make sense to do some arch
detection at runtime, but the init which does so should probably be off
by itself, rather than needing to be ifdef'd out.

> I want to get rid of ifdefs.  When creating the generic desktop kernel the
> comparisons in the 'if' (not ifdef) are done.  When compiling for a
> specific arch the _machine value is no longer a variable but a constant.
> The compile optimizes out the 'if' and gives you a straight path.

Does the switch get optimized in the same way? ie.
  m = 4;
  switch(m) {
    case 1:
      printf("Will this no generate code?\n");
      break;
    case 2:
    case 4:
      /* is this the only code compiled? */
    case 8:
  }
-- 
   -bill davidsen (davidsen@prodigy.com)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Restructuring Efforts

[Gabriel Paubert]

On Tue, 16 Feb 1999, Christian Zankel wrote:

> Actually, the Force PowerCore 6750 has nothing (or almost nothing). I've
> just started with the port, but ran
> into some difficulties: There seems to be a lot of dependencies between
> different machines (ie. pmac, prep, chrp, mbx, etc.), I didn't want to
> pay attention to. (E.g. I do not need PMac's keyboard and SCSI driver,
> which seems to be compiled in per default. Especially, I do not need any
> calls to read the OF tree, residual data, etc.)

Actually it seemes the board uses an MPC106, so it must have either a PreP
like map or a CHRP like one (it might even be switchable with a jumper).

> I've seen that you have setup a directory for those patches. But
> couldn't you start with a seperate cvs tree to move the process of
> restructuring the kernel forward? I mean, having a kind of 'official'
> inofficial LinuxPPC developer kernel. I'd also really appreciate it if
> there could be a kind of a statement(?) and perhaps a short discussion
> about the restructured arch/ppc tree. I'd like to ask especially you,
> Cort, as you seem to be the maintainer of the LinuxPPC port, how you see
> the restructured arch/ppc tree. I'd like to help, but need to know where
> arch/ppc is going to be. 
> 
> I hope that a little discussion is allowed here:
> (Please, understand that my point of view is from a board where the
> initialization is different from those with an OF)
> 
> 1. Directory Structure
> It seems that efforts are going to create one 'super' PPC-kernel
> suitable for all the PPC machines.
> I can't say that I'm really happy about it. I think there might be more
> overhead, unreadibility (i.e. a lot #ifdef's), bigger kernels, etc. I'd
> like to see the Macintosh, PreP, CHRP, etc. more seperated, ie. in
> different directories (one for pmac, prep, chrp, apus, mbx, pcore6750,
> etc.) I think, it's then much easier to add new machines, new PPC
> generations, etc. Short: I don't think is wise to have only one
> CONFIG_PMAC_PREP_CHRP_?_? for all machines and let the kernel decide at
> boot time what to do. Do I overlook here something?

Not that much, actually once you smooth out the differences in:
a) the interrupt controllers,
b) the address at which you access PCI I/O space,
c) the way you access PCI configuration space,
d) a few oddities like virt_to_bus and offsets to access PCI MMIO space
   (ioremap).

PreP, CHRP and PMAC are very similar, except for individual drivers, so it
makes sense to have common files. The 4/5/8xx series on the other hand are
so different from the 6xx/7xx (espcially the MMU) that some files should
indeed be splitted and the ifdef moved up to the Makefile level.

> 2. kernel/head.S
> It seems that the basic initialization varies from board to board.
> Porting LinuxPPC to the Force board would result in more #ifdef's. I'd
> suggest to seperate the 'exceptions' part (into trap.S) from the
> initialization code and put the later one into the mach-dirs.
> 
> 3. OF
> The Force board has no OF and no residual structures. What I have in
> mind is to replace the firmware of the board completely with a MILO-like
> firmware. This firmware should be able to boot an elf-vmlinux image
> either from the same flash, or the user-flash, from network, or scsi.
> Would it possible to seperate the calls to read data from OF and to read
> residual data, from the generic sources (especially in arch/ppc/mm) ? 

That's one of my goals on an MVME board, I'm going to upload patches with
a new prepboot directory which now needs more widespread testing. For now
it relies on residual data, but it should be less necessary on every
iteration (except for interrupt routing which is hopeless on some boards).

I'd rather see it the other way around, the MILO-like should be board
specific and build a minimal parameter table for the kernel so that the
same kernel can run on different boards. Note that prepboot enables the
MMU and maps all memory and I/O with correct attributes so that it would
probably allow the addition of simplified drivers to the ROM image (it
also includes a simple but powerful enough for most cases memory
management system). It also includes an x86 emulator which allows me to
initialize my S3 Trio64 PMC board, which was never working properly with
earlier versions of PPC vga init code. 

The only thing I did not want to add was interrupt handling. So the
drivers will have to be modified to do polling, I don't think that this is
an issue in a bootloader: it would make it more fragile for no good
reason.

	Regards,
	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]