Re: suggested improvements to ease porting
Vincent Stemen wrote:[color=blue]
> On 2005-11-08, Sanky <email@example.com> wrote:[color=green]
> > Yes, I agree.
> > After looking at the MACH source (source organization borrowed from
> > BSD) and the BSD code itself, I believe that BSD has probably the best
> > organization.
> > But I think an organization like BSD's will definately lead to easy
> > ports but will make it slightly difficult for most of the students that
> > follow Andy's book.[/color]
> > I think a plethora of Makefiles only make source confusing.
> > Lets see if this community can come up with somthing original and
> > innovative.[/color]
> I assume you are referring to the way NetBSD's makefiles include other
> makefiles which include other makefiles which often combine thousands of
> lines of makefile code :-).
> I didn't mean that I think the makefiles should necessarily be written
> the way NetBSD's are. IMHO they are too complex (although, I am not
> sure how avoidable this is when supporting that many platforms).
> I think Makefiles should primarily be used just to define source
> dependencies and simple commands. Any script that is required beyond
> that should be in external shell scripts whenever possible. I think
> both the GNU and BSD communities often go overboard in the usage of
> I think we should always strive to keep each makefile self contained and
> as simple as possible.
> NetBSD does strive to make the Makefiles for individual source trees
> very simple though, by including common code from the top level makefile
> library. This actually causes most of the individual makefiles in the
> source tree to be very small and simple. Their approach is admirable
> and should probably be studied for ideas at least.
> However, in my original followup, I was primarily referring to the
> kernel directory and file layout that NetBSD uses with a sub-directory
> for each port with it's own conf, include, etc .. directories and it's
> own makefile. The way they have theirs laid out seems to be pretty
> clean and elegant. It is working well with NetBSD supporting over 50
> different platforms.
> For those unfamiliar with NetBSD, when you compile for a given platform,
> you get a clean compilation directory under
> arch/<platform>/compile/<config-name> with it's own makefile.
> For example:
> Suppose you are compiling for i386. You optionally edit a configuration
> file under arch/i386/conf for any customizations you want to make for
> that kernel. Lets call the conf-file mykern. To compile, these are the
> config mykern
> make depend
> cd ../compile/mykern
> You get a compilation directory under arch/i386/compile/mykern/.
> Pretty clean and simple, and you can compile for multiple architectures
> and even different custom configurations for each architecture, all
> within the same source tree. If, for example, you wanted to modify the
> same kernel for your firewall machine, you could do something like this
> cd arch/i386/conf
> cp GENERIC firewall
> vi firewall
> config firewall
> make depend
> cd ../compile/firewall
> Now you will have an additional directory with your new compiled kernel
> in arch/i386/compile/firewall/
> I am recommending looking closely at the NetBSD model because I think
> Minix, with it's clean design, could easily support as many or even more
> platforms than NetBSD in the future.
> Vincent Stemen
> Avoid the VeriSign/Network Solutions domain registration trap!
> Read how Network Solutions (NSI) was involved in stealing our domain name.
Vincent Stemen wrote:
> However, in my original followup, I was primarily
> referring to the kernel directory and file layout
> that NetBSD uses with a sub-directory for each
> port with it's own conf, include, etc ..
> directories and it's own makefile. The way they
> have theirs laid out seems to be pretty clean and
> elegant. It is working well with NetBSD supporting
> over 50 different platforms.[/color]
I spent my last few days of free time experimenting with NetBSD for the
first time. It is excellent. I enthusiastically endorse your
recommendation that the NetBSD directory organization be considered as
the model for MINIX multi-platform support.
In addition to leveraging the existing investment in thought by clear
thinking people that led to the NetBSD directory organization, it has
the additional benefit that there should be a natural synergism between
NetBSD and MINIX developers since both implementations have an embedded
focus; and the degree to which the MINIX directory layout is familiar
eases the transition for embedded developers accustomed to NetBSD.
> I am recommending looking closely at the NetBSD
> model because I think Minix, with it's clean design,
> could easily support as many or even more platforms
> than NetBSD in the future.[/color]
This is what I am hoping for as well. Use NetBSD with its richer API
where footprint is not an issue, and use MINIX with its more limited
API where constrained by hardware. The dream scenario would be that
MINIX 3 is sufficiently POSIX compatible that much embedded code (not
driver level, obviously) could migrate between these two operating
systems with minimal changes.