[ppc-dev] Summary: Restructuring Efforts

[ppc-dev] Summary: Restructuring Efforts

[Christian Zankel]

Hello,

Well, I started (yet again) with some questions and remarks about
restructuring the kernel, so I guess I should summarize the outcome so
far. I tried to summarize all statements I got so far (you will find the
individual summaries below). I hope that I didn't made major mistakes in
language usage or that I mixed up the statements (If so, I'm sorry and I
apologize for it).

1. CVS

There should be another cvs tree used for developers. A lot of
(inofficial) patches are floating around. So, this tree can be used as
the common base where developers can start with their patches upon.
These patches will be (carefully) added (by Cort). There is no need for
r/w access for everyone. However, it is a developers kernel, so patches
can be made much easier in this tree than in an official one. Perhaps
the use of bitkeeper might also be of help.

2. GENERIC KERNEL

Cort wants to have one generic kernel for all desktops. There are
difficulties with APUS because of the 'non byte swapping io accesses',
though. 
The usage of OpenFirmware by supporting functions should be compiled in
into the generic kernel. Using the variable _having_of will then help to
decide whether to use these functions or not. This can happen either at
run-time or, when _having_of is made a constant, the optimizer of gcc
will/might remove this code. 
Arch specific functions might be grouped into a structure. This
structure is initialized at startup.  
To many integration might result in performance penalty because of to
many functionpointer lookups. Though, careful design (cache boundaries)
of this structure might reduce this performance penalty.
Traps might also be useful to emulate unsupported processor
instructions. 

3. SEPARATIONS

There have been no suggestions so far about if and how all the pmac_*,
prep_*, etc. should be seperated into a seperate directory. However,
Cort stated that head.S will be seperated.
After the restructuration is completed, it is then easy to support
different machines by just dropping another directory into the arch/ppc
directory and doing some minor changes to the Makefile and maybe also to
config.in.


Of course, I'd like to add some comments here:

1.
This is actually what I had in mind when asking about another cvs tree.
If you ask about r/w access, I guess everyone working on a port would
like to have r/w access, but this is not what I had in mind initially. 
I guess, a lot people are using Corey+Troy+... patches. These are the
patches I would see to be in the developers cvs. (Or declared as the
'official developers' patch, or whatever... )

2.
I also started with Corey's patches. So, many things are already
seperated. However, I ran into difficulties with the initialization
routines, mainly head.S and mm/init.c. Routines like those are only used
during initialization and, I think, are not needed to be made generic. 
Having a structure for the arch specific functions are only necessary if
you want to support different architectures at run time. Perhaps it's a
better to 'let the linker decide' which system the kernel should be
linked to. You could even use a library (with ar) of generic functions
having the same function names as the system specific object file. These
library functions are then 'overwritten' by the system specific
functions.
I don't like having OF supporting functions automatically built in into
the kernel when they are not needed. I'm not sure (right now) how easy
it is to build an interface between the kernel and those functions (eg.
in arch/ppc/mm).

3.
I'd like to see the pmac_*, chrp_*, prep_* stuff put into seperate
directories. 
I think head.S could be seperated into a system specific head.S and
trap.S. 



Thanks,
Christian

--------
Individual Summaries

Cort
- wants to avoid another tree for restructuring
- asks for a 'behaved' redesign (ie. not quick'n'dirty)
- bootloader cleanups are underway (eg. mbxboot for embedded)
- 2.2 supposed to be stable with only few changes; restructuring is
necessary, though
- there is a FTP access for patches; different ideas for restructuring
should be evaluated
- only 'mainstream' boards should be supported in kernel, but easy
integration should be possible
- single kernel for all desktops ('cos they have enough RAM and it's
easier to test); embedded: specifically for target
- generic kernel for PMAC,CHRP,PreP,APUS
- kernel/head.S will be seperated
- code supporting openFirmware only used in init-sections which get
dropped (possibly: use of have_of)
- generic kernel with constant _machine values are optimized by the
compiler

Troy
- careful redesign should result into a second tree on a central place
- a large bunch of incompatible chaotic patches floating around
- this 'bleeding edge tree' might also be easier to integrate into 2.3
- favours Corey's work to seperate archs

Cort
- cvs problems:
  o move things from our tree to vger to linus; vger important for
testing
  o to many, perhaps also imcompatible patches might come in
- asking how many people would like to have cvs r/w access
- there are only a few mostly overlapping patches
- use vger instead of an own cvs
- corey's work will be integrated soon
- restructuring efforts: corey's work, irq.c, pci-config

Gabriel
- there is no need for r/w access
- vger is to public; no real developer tree as we need it
- there are problems accessing vger
- is using currently a kernel with corey,troy,prepboot and a few own
patches
- APUS I/O needs 'non byte swapped instructions'
- kernel shouldn't execute conditional code or a call to subroutine for
every I/O access

Bill
- Current work not supposed to get into 2.3
- supporting multiple archs indicates to use directories rather than
putting everything inline with ifdefs
- easy to support another arch by dropping the directory and changing
symbolic links and changes to generic part mostly have not impact
- generic kernel desires also an 'all purpose' init in a dir of its own
- possible use of arrays of functions like *fct[_machine], or defines
for the functions

Benjamin
- prefers own cvs for developers tree instead of vger 

Troy
- we should try out bitkeeper

Benjamin
- likes function pointers (eg. in structures) 
- optimizing tables to cache boundaries

David
- BSD is using static structures with pointers to certain routines

Gabriel
- is against using vger

Jesper
- APUS doesn't require byte swapping; however, he doesn't see the
problems for integrating APUS into the generic kernel
- is also concerned having additional memory accesses to call IO
subroutines using function pointers

Gabriel
- integrating APUS desires having also pointers to IO functions
resulting in a huge performance penalty 
- (see. io.h)

Cort
- using traps to emulate non existant instructions like tlbia



-- 
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: [ppc-dev] Summary: Restructuring Efforts

[Paul Mackerras]

Christian Zankel <zankel@tarantel.rz.fh-muenchen.de> wrote:

> There should be another cvs tree used for developers. A lot of
> (inofficial) patches are floating around. So, this tree can be used as
> the common base where developers can start with their patches upon.

I think a CVS tree for developers is a good idea.  In fact I think we
need two trees; one for developers to share their latest thoughts, and
another one where we put stuff once it is tested and known not to
break things for most users.  The second tree would then be the one
from which patches get sent to Linus.

If we do that, then we can give relatively wide access to the
development tree, and restrict access to the stable tree to one or two
people (Cort and I, maybe).  That way the divergence of the stable
tree from Linus' could be controlled.

Ideally the trees should provide read-only rsync access since that is
so much more efficient for people who are a long way from the cvs
server.

I would think that dev.linuxppc.org is probably the best place to keep
these trees.

> Cort wants to have one generic kernel for all desktops. There are
> difficulties with APUS because of the 'non byte swapping io accesses',
> though. 

There is some value in having a generic kernel for the desktops (PReP,
powermac, CHRP), particularly if they can all boot an ELF image.

As for APUS, I think it is sufficiently different that having a
separate APUS-only kernel is not a problem.  The various embedded
ports don't want a generic kernel because space is usually at a
premium.

> The usage of OpenFirmware by supporting functions should be compiled in
> into the generic kernel. Using the variable _having_of will then help to
> decide whether to use these functions or not. This can happen either at
> run-time or, when _having_of is made a constant, the optimizer of gcc
> will/might remove this code. 

If there is no device tree, then it should still be safe to call the
device-tree routines (e.g. find_device, etc.) because the variable
holding the root of the tree will be initialized to NULL, so
find_device etc. should just return NULL.  If necessary, a port could
define these as macros to save space.  It would be too ugly to have to
check _have_of each time before calling any device-tree routines.

> There have been no suggestions so far about if and how all the pmac_*,
> prep_*, etc. should be seperated into a seperate directory. However,

We thought about having separate prep, pmac, chrp etc. directories
back when we were integrating the prep and pmac ports.  At that stage
it was easier just to have a single directory since the amount of
common code outweighed the port-specific code.

I would definitely support having a separate directory for the
860-based ports, since they are substantially different, even the MMU
works quite differently.  Maybe separate directories for the desktops
and the embedded ports would work well.

Paul.

[[ 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] Summary: Restructuring Efforts

[Cort Dougan]

Thanks for the summary, that stated things far more eloquently and
succinctly than I did.

My understanding was that the idea of a linux/ppc developers tree would be
that nearly all the people sending patches could have access.  Was that
not the idea?  The description here sounds like the vger tree.  The vger
tree is play-land for ppc.

}1. CVS
}
}There should be another cvs tree used for developers. A lot of
}(inofficial) patches are floating around. So, this tree can be used as
}the common base where developers can start with their patches upon.
}These patches will be (carefully) added (by Cort). There is no need for
}r/w access for everyone. However, it is a developers kernel, so patches
}can be made much easier in this tree than in an official one. Perhaps
}the use of bitkeeper might also be of help.

I want to have the ability to generate one - I don't want to require it.
I like being able to test 3 archs at once.  I don't like users having to
have a lot of code slowing their machine down if they only use chrp, pmac
or prep and want to build their own arch-specific kernel.

}2. GENERIC KERNEL
}
}Cort wants to have one generic kernel for all desktops. There are
}difficulties with APUS because of the 'non byte swapping io accesses',
}though. 
}The usage of OpenFirmware by supporting functions should be compiled in
}into the generic kernel. Using the variable _having_of will then help to

Already done.

}decide whether to use these functions or not. This can happen either at
}run-time or, when _having_of is made a constant, the optimizer of gcc
}will/might remove this code. 

Putting this critter on a few cache lines is a winner of an idea.  I think
this idea needs some work but what Cory+others (sorry, but I've lost track
of what path this idea has followed :) have come up with is a good
direction.

}Arch specific functions might be grouped into a structure. This
}structure is initialized at startup.  
}To many integration might result in performance penalty because of to
}many functionpointer lookups. Though, careful design (cache boundaries)

head.S just needs to be taken apart for different chips.  8xx, 4xx, 5xx
and 6xx/7xx are too different to try to share.  I've learned my lesson
with the mistake of trying to keep one head.S.  There's a lot of common
code in there that we could call arch-head.S or some such thing.

}3. SEPARATIONS
}
}There have been no suggestions so far about if and how all the pmac_*,
}prep_*, etc. should be seperated into a seperate directory. However,
}Cort stated that head.S will be seperated.
}After the restructuration is completed, it is then easy to support
}different machines by just dropping another directory into the arch/ppc
}directory and doing some minor changes to the Makefile and maybe also to
}config.in.

This is the most important thing to me.  Lots of people have good ideas
but I want to make sure we won't be suffering growing pains too soon again
(for a few months at least).  Many more ports to different systems/chips
are looming and I'd like to make sure the design isn't going to stop us.
I'd also like for machine maker X with patches I don't want to bring into
the kernel (too limited use, too messy or whatever) or because they don't
want them in (proprietary board) can drop in their changes quickly and
easily (within reason).


}- asks for a 'behaved' redesign (ie. not quick'n'dirty)
}- bootloader cleanups are underway (eg. mbxboot for embedded)

The stability issue isn't quite fully realized due to general linux
problems right now, though.

}- 2.2 supposed to be stable with only few changes; restructuring is
}necessary, though

Actually, I'm not saying I dislike the design or don't want to use it.  I
want more people to look at it and try it on their boards to make sure it
works for them.  Mostly the embedded board people (not mbx/rpx, but
mtx,mvme,prep and so on).

}- there is a FTP access for patches; different ideas for restructuring
}should be evaluated

I like that idea as well.  If people really want a linux/ppc CVS I'm
willing to set it up and maintain it.  We should figure out how we'll do
it though.  I like keeping on the bleeding edge but every patch breaking
another arch isn't a good thing :)  I think bitkeeper might help us out,
but it seems to me to work similar to individual cvs trees with a script
to create patches (I'm oversimplifying quite a bit) and shipping them via
email - I know Larry would disagree but from my end-user view it seems to
work this way.

}Benjamin
}- prefers own cvs for developers tree instead of vger 
}Troy
}- we should try out bitkeeper

In the end, I think I do have to use vger.  If only as a stepping stone
from any other ppc trees before going to linus.

}Gabriel
}- is against using vger

My ideas was to do lazy filling-in of structures and/or function pointers.
This falls into the 'half-baked' drawer so I'm not suggesting it as a real
possiblity yet.

}Cort
}- using traps to emulate non existant instructions like tlbia


[[ 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] Summary: Restructuring Efforts

[Cort Dougan]

My concern here is that moving things to vger/linus could be difficult if
the trees diverge too much.  It might sometimes be necessary to revert
some changes because they're not ready yet or break things.  I think that
detail can be worked out then, though.

}another one where we put stuff once it is tested and known not to
}break things for most users.  The second tree would then be the one

If vger were the stable tree, that would be great.  I'd like more of the
community able to get their hands on things through the dev tree rather
than having to grab day old tar files from me.

}If we do that, then we can give relatively wide access to the
}development tree, and restrict access to the stable tree to one or two
}people (Cort and I, maybe).  That way the divergence of the stable
}tree from Linus' could be controlled.

If I'm setting it up and maintain it I'd prefer it here.  I can more
easily fix things and setup things that way.  Hosting the mail exploder
and a mirror at linuxppc.org would be great.

}Ideally the trees should provide read-only rsync access since that is
}so much more efficient for people who are a long way from the cvs
}server.
}
}I would think that dev.linuxppc.org is probably the best place to keep
}these trees.


[[ 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] Summary: Restructuring Efforts

[Hartmut Koptein]

> There is some value in having a generic kernel for the desktops (PReP,
> powermac, CHRP), particularly if they can all boot an ELF image.
                                                     ^^^^^^^^^^^^^
          Yeah, thats the point!  And some compile errors!
						     
Thanks,

     Hartmut

[[ 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] Summary: Restructuring Efforts

[Michael Meissner]

On Fri, Feb 19, 1999 at 05:12:21PM +1100, Paul Mackerras wrote:
> 
> Christian Zankel <zankel@tarantel.rz.fh-muenchen.de> wrote:
> 
> > There should be another cvs tree used for developers. A lot of
> > (inofficial) patches are floating around. So, this tree can be used as
> > the common base where developers can start with their patches upon.
> 
> I think a CVS tree for developers is a good idea.  In fact I think we
> need two trees; one for developers to share their latest thoughts, and
> another one where we put stuff once it is tested and known not to
> break things for most users.  The second tree would then be the one
> from which patches get sent to Linus.

Why do people keep mentioning a second tree, and not using something like a
branch off of the main cvs tree?  Within egcs, we use branches for separate
development tasks (1.1.x and mainline).  In fact right now, I have my own
branch for the PowrerPC compiler changes.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

[[ 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] Summary: Restructuring Efforts

[Matt Porter]

> There is some value in having a generic kernel for the desktops (PReP,
> powermac, CHRP), particularly if they can all boot an ELF image.

PReP and CHRP machines are not necessarily desktops/servers.

--
Matt Porter
mmporter@home.com
Unix is a Linux-like operating system.


[[ 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] Summary: Restructuring Efforts

[Cort Dougan]

The concern in this discussion (If I'm following along correctly) is RAM
size, that's all.  The PReP bootloader works on MTX even though it's not
in the embedded dir.  Since RAM is the issue how much RAM does a typical
MTX installed system have?  Do they boot from flash or from a hd once
deployed?

}PReP and CHRP machines are not necessarily desktops/servers.


[[ 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] Summary: Restructuring Efforts

[Hartmut Koptein]

On Feb 19, Matt Porter wrote:
> 
> > There is some value in having a generic kernel for the desktops (PReP,
> > powermac, CHRP), particularly if they can all boot an ELF image.
> 
> PReP and CHRP machines are not necessarily desktops/servers.

Hmmm ... why not? You mean only for workstations? I have an chrp here on
my desktop. And for servers ... the bandwith is a problem, yes. 

But a generic (common) kernel-image is much, much easier for distribution.
Only one cd, one boot-floppy, one setup ... 

Regards,

     Hartmut

[[ 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] Summary: Restructuring Efforts

[Michael Meissner]

On Fri, Feb 19, 1999 at 01:21:35PM -0700, Cort Dougan wrote:
> 
> The concern in this discussion (If I'm following along correctly) is RAM
> size, that's all.  The PReP bootloader works on MTX even though it's not
> in the embedded dir.  Since RAM is the issue how much RAM does a typical
> MTX installed system have?  Do they boot from flash or from a hd once
> deployed?

Note, on my little PowerStack with 48 meg of memory, the new bootloader does
not work (as I reported previously -- there are no messages after the prompt).
The old bootloader works on the machine, but not on my big Utah PowerStack with
128 meg of memory.

> }PReP and CHRP machines are not necessarily desktops/servers.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

[[ 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] Summary: Restructuring Efforts

[Paul Mackerras]

Michael Meissner <meissner@cygnus.com> wrote:

> Why do people keep mentioning a second tree, and not using something like a
> branch off of the main cvs tree?  Within egcs, we use branches for separate
> development tasks (1.1.x and mainline).  In fact right now, I have my own
> branch for the PowrerPC compiler changes.

Two reasons, the main one being access control, the secondary one
being that we may want to have the two trees maintained by different
people in different places.

I don't think having two trees, keeping track of the differences, and
merging changes from one to another is a big problem.  I have this
Tk-based tool called `dirdiff' for visualizing the differences between
up to 5 trees.  If anyone wants to have a look at it, it's in
ftp://samba.anu.edu.au/pub/linux-pmac/misc/dirdiff.  It's still a
little rough around the edges and it doesn't have any documentation,
but it may be useful.

Paul.

[[ 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] Summary: Restructuring Efforts

[Matt Porter]

On Fri, 19 Feb 1999, Cort Dougan wrote:

I was concerned that people might think that ALL embedded boards would
fall into the "embedded" bootloader and it could cause confusion down the
line.  I think most MTX systems out there are running 32MB+ usually.  I
can't answer for sure what most are using as a boot device, but it does
vary.  Usually it's going to be out of FLASH since it is intended and
priced for rugged embedded applications.  Since VxWorks runs on most MCG
boards in general, you can bet that it is quite common to boot out of
FLASH.
  
> The concern in this discussion (If I'm following along correctly) is RAM
> size, that's all.  The PReP bootloader works on MTX even though it's not
> in the embedded dir.  Since RAM is the issue how much RAM does a typical
> MTX installed system have?  Do they boot from flash or from a hd once
> deployed?
> 
> }PReP and CHRP machines are not necessarily desktops/servers.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ 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] Summary: Restructuring Efforts

[Cort Dougan]

Thus the name arch/ppc/mbxboot rather than emb_boot or some such thing.
They're all not mbx, but that makes it more clear that it's for mbx-type
boards (rather than prep/mtx).

}I was concerned that people might think that ALL embedded boards would
}fall into the "embedded" bootloader and it could cause confusion down the


[[ 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] Summary: Restructuring Efforts

[Matt Porter]

On Mon, 22 Feb 1999, Cort Dougan wrote:

How about miscboot?  I know, I know, it's not that big of deal...

> Thus the name arch/ppc/mbxboot rather than emb_boot or some such thing.
> They're all not mbx, but that makes it more clear that it's for mbx-type
> boards (rather than prep/mtx).
> 
> }I was concerned that people might think that ALL embedded boards would
> }fall into the "embedded" bootloader and it could cause confusion down the

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ 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] Summary: Restructuring Efforts

[Cort Dougan]

miscboot might be used later for common bootloader code.

}How about miscboot?  I know, I know, it's not that big of deal...


[[ 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 ]]