Hi everyone,
In looking at the modules/ subdirectory, it seems to me that it is actually serving multiple purposes. Not only does it contain C implementations for Forth words defined within various extension packages, but also various random library routines.
I'd like to propose creating a new directory called common/ and moving any files that don't contain C implementations of package words into this new directory. With this in place, I think it will be possible to share more files between the various architectures; in particular I think it will be possible to use one set of code for each of the different *-loaders, rather than requiring separate implementations for each architecture (e.g. arch/*/elfload.c).
Thoughts/comments?
ATB,
Mark.
On 3/7/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi everyone,
In looking at the modules/ subdirectory, it seems to me that it is actually serving multiple purposes. Not only does it contain C implementations for Forth words defined within various extension packages, but also various random library routines.
I'd like to propose creating a new directory called common/ and moving any files that don't contain C implementations of package words into this new directory. With this in place, I think it will be possible to share more files between the various architectures; in particular I think it will be possible to use one set of code for each of the different *-loaders, rather than requiring separate implementations for each architecture (e.g. arch/*/elfload.c).
Good plan, though "common" does not describe the directory contents well. I don't have a better name in hand (misc: vague, arch/common: same problem, loaders: could be something else, core: not so core stuff, kernel: already taken).
Blue Swirl wrote:
Good plan, though "common" does not describe the directory contents well. I don't have a better name in hand (misc: vague, arch/common: same problem, loaders: could be something else, core: not so core stuff, kernel: already taken).
Yeah, I know what you mean. How about keeping the non-package specific C files in modules/ but then creating a new packages/ subdirectory to store the package C implementations?
ATB,
Mark.
Mark Cave-Ayland wrote:
Good plan, though "common" does not describe the directory contents well. I don't have a better name in hand (misc: vague, arch/common: same problem, loaders: could be something else, core: not so core stuff, kernel: already taken).
Yeah, I know what you mean. How about keeping the non-package specific C files in modules/ but then creating a new packages/ subdirectory to store the package C implementations?
Please find attached a preliminary patch that implements the above. I'm still not 100% sure on the directory names, however I hope the diff shows the idea behind what I'm trying to do. As well as moving files to a different directory, I've also tidied up a few naming conventions to make things easier to follow.
ATB,
Mark.
Mark Cave-Ayland wrote:
Please find attached a preliminary patch that implements the above. I'm still not 100% sure on the directory names, however I hope the diff shows the idea behind what I'm trying to do. As well as moving files to a different directory, I've also tidied up a few naming conventions to make things easier to follow.
Does anyone have any further thoughts on this, particularly Stefan? I'd like to get this committed reasonably soon.
In terms of renaming the existing modules/ directory, my favourite candidates for names at the moment are libopenbios and libmisc.
ATB,
Mark.
On 3/12/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Mark Cave-Ayland wrote:
Please find attached a preliminary patch that implements the above. I'm
still not 100% sure on the directory names, however I hope the diff shows the idea behind what I'm trying to do. As well as moving files to a different directory, I've also tidied up a few naming conventions to make things easier to follow.
Does anyone have any further thoughts on this, particularly Stefan? I'd like to get this committed reasonably soon.
In terms of renaming the existing modules/ directory, my favourite candidates for names at the moment are libopenbios and libmisc.
One dimension for organizing the directories could be "internal" (only used by C) vs. "external" (exported to Forth or client interface etc.).
I also looked at Linux directory structure, it has some match but not complete.
Anyway, your version is a good starting point.
Blue Swirl wrote:
One dimension for organizing the directories could be "internal" (only used by C) vs. "external" (exported to Forth or client interface etc.).
I also looked at Linux directory structure, it has some match but not complete.
Anyway, your version is a good starting point.
Hmmm that's true - it's fairly easy to rename the directory at a later date if we come up with something better. I've just committed a revised version of the patch which uses libopenbios until we can come up with something better.
ATB,
Mark.
On 3/13/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
One dimension for organizing the directories could be "internal" (only used by C) vs. "external" (exported to Forth or client interface etc.).
I also looked at Linux directory structure, it has some match but not
complete.
Anyway, your version is a good starting point.
Hmmm that's true - it's fairly easy to rename the directory at a later date if we come up with something better. I've just committed a revised version of the patch which uses libopenbios until we can come up with something better.
I think you forgot one file: Initializing build tree obj-ppc...ok. Creating target Makefile...warning: failed to load external entity "../packages/build.xml" ok.
make: *** No rule to make target `libpackages.a', needed by `openbios-builtin.elf'. Stop.
Blue Swirl wrote:
I think you forgot one file: Initializing build tree obj-ppc...ok. Creating target Makefile...warning: failed to load external entity "../packages/build.xml" ok.
make: *** No rule to make target `libpackages.a', needed by `openbios-builtin.elf'. Stop.
Yes, you're right - looks like I forgot to "svn add" several other files too :( I think my last commit should have now fixed this - could you please check again at your end?
ATB,
Mark.
On 3/13/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
I think you forgot one file: Initializing build tree obj-ppc...ok. Creating target Makefile...warning: failed to load external entity "../packages/build.xml" ok.
make: *** No rule to make target `libpackages.a', needed by `openbios-builtin.elf'. Stop.
Yes, you're right - looks like I forgot to "svn add" several other files too :( I think my last commit should have now fixed this - could you please check again at your end?
Yes, build is fixed now.
Blue Swirl wrote:
Yes, build is fixed now.
Cool. I'm now taking a look at synchronising the layout between the OpenBIOS code directories and the include/ directory hierarchy and would like to suggest some changes here too.
In particular, I'd like to propose the following re-organisation:
1) Move the architecture specific dirs from include/ to include/arch 2) Match the directory structure with the OpenBIOS code, e.g.
include/arch/.../ include/drivers/ include/kernel/ include/libc/ (already there) include/libopenbios/
The only thing I am currently undecided upon is where to put the configuration files, e.g. config.h, sysinclude.h and mconfig.h. Should these just go directly under include/?
ATB,
Mark.
On 3/13/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Blue Swirl wrote:
Yes, build is fixed now.
Cool. I'm now taking a look at synchronising the layout between the OpenBIOS code directories and the include/ directory hierarchy and would like to suggest some changes here too.
In particular, I'd like to propose the following re-organisation:
- Move the architecture specific dirs from include/ to include/arch
This is like what Linux used to do. I like slightly more how it's done currently in Linux (arch/*/include) but this could require that arch specific stuff lives completely inside arch/* and this is not the case for for example PCI and other drivers.
- Match the directory structure with the OpenBIOS code, e.g.
include/arch/.../ include/drivers/ include/kernel/ include/libc/ (already there) include/libopenbios/
Good idea.
The only thing I am currently undecided upon is where to put the configuration files, e.g. config.h, sysinclude.h and mconfig.h. Should these just go directly under include/?
Probably.
Blue Swirl wrote:
- Move the architecture specific dirs from include/ to include/arch
This is like what Linux used to do. I like slightly more how it's done currently in Linux (arch/*/include) but this could require that arch specific stuff lives completely inside arch/* and this is not the case for for example PCI and other drivers.
- Match the directory structure with the OpenBIOS code, e.g.
include/arch/.../ include/drivers/ include/kernel/ include/libc/ (already there) include/libopenbios/
Good idea.
The only thing I am currently undecided upon is where to put the configuration files, e.g. config.h, sysinclude.h and mconfig.h. Should these just go directly under include/?
Probably.
Okay - the reorganisation is now complete :) It was quite a challenge to try and work out how some of the header files should be split, but I think that it makes the overall source tree much easier to follow.
The only outstanding issue so far is that the PPC build was broken by r693. I can't quite see at the moment why this is the case, so any pointers would be appreciated...
ATB,
Mark.
Mark Cave-Ayland wrote:
The only outstanding issue so far is that the PPC build was broken by r693. I can't quite see at the moment why this is the case, so any pointers would be appreciated...
I think I've fixed this. Taking a look at arch/ppc/qemu/qemu.c compared to the other PPC machine types (arch/ppc/briq/briq.c and arch/ppc/pearpc/pearpc.c) seemed to indicate that arch/ppc/qemu/qemu.c was missing a definition for virt_offset.
Adding this in seems to fix the compilation, however it may be a good idea for the PPC folk to do a fresh SVN checkout to make sure I didn't break anything with this...
ATB,
Mark.
-
Blue Swirl -
Mark Cave-Ayland