Re: [minix3] Recompiling Minix Kernel

[Alex Buell]

On Sat, 2012-06-16 at 15:22 -0700, John Doe wrote:
> I'm currently enrolled in my university's operating systems class.
> We've just got our first project involving Minix 3.2.0, which I've
> installed on Virtual Box. I've made all the project's specified
> changes to Minix's source code, which involve changing the OS version
> number and modifying the start up banner message, but I'm having
> trouble rebuilding and reinstalling the kernel. I've seen the
> Developer's Guide page on rebuilding the system here and tried
> everything from rebuilding just the kernel to a full-blown make world.
> I've also done some googling on the subject. I even emailed our
> professor about this a few days ago, but I have yet to receive a
> response. However, no matter what I try, I always get the same login
> message, instead of the one I specify in the source code. The
> deadline for the project is this Wednesday (6/20), so I'm starting to
> get a little nervous. Would anyone be able to give me some guidance?

What does /etc/issue say?
--
Tactical Nuclear Kittens

[John Doe]

First off, I had a backup of my Minix VM that was completely stock, no modifications.  I overwrote my old one that I had tinkered with with the stock one to make sure I hadn't broken something inadvertently.  With the stock VM, I installed openssh so I could fetch my modified source files.  I put them back in their respective places.  I then issued the following commands logged in as root:  su, cd /usr/src, make world. 

As for the output of /etc/issue, the file doesn't exist. 

Next, I looked at my two modified files and found out that after the make world, one of them reverted itself to its unmodified state.

Then I rebooted, letting Minix boot with default options by letting the timer expire.  None of my changes appeared.

This is getting really perplexing...

[pikpik]

Hi,

On Jun 16, 6:22 pm, John Doe wrote:

> I'm currently enrolled in my university's operating systems class. We've
> just got our first project involving Minix 3.2.0, which I've installed on
> Virtual Box. I've made all the project's specified changes to Minix's
> source code, which involve changing the OS version number and modifying the
> start up banner message, but I'm having trouble rebuilding and reinstalling
> the kernel.

There are a few places where "Welcome" appears:
http://git.minix3.org/?p=minix.git&a=search&h=HEAD&st=grep&s=Welcome

Everything in src/tools will take effect in a release/installer image
you can create (using release.sh).

Also, does your change effect the boot prompt? The bootloader isn't
updated by "make world." You might want to run "make" in src/tools to
see options.

I wish I could help,
pikpik

[John Doe]

Wow, I had completely forgotten about this thread.  The good news is I forgot in my joy of solving my problem.  It turned out I had the wrong location for the version number change.  There are two directories in Minix that are very similar:  /usr/include/minix/config.h and /usr/src/include/minix/config.h.  It seems that when you recompile the Minix kernel, it takes all the includes in the /usr/src/ directory and moves them to the /usr/ directory, then compiles from the /usr/src/ tree.  Since I was modifying the the config.h file in the /usr/ tree, all my changes were being stepped on by the config.h file in the /usr/src/ tree, then the compilation process was using unmodified files.  Hence my changes disappearing.

For someone who is new to programming an operating system, this was a really subtle bug, especially since I've done a lot of other C/C++/Java programming and have never seen behavior like this in a system before.  It might be worth it for the devs to put a readme in the /usr/include/minix/ directory that says something to the effect of, "This gets overwritten at compile time!"  Hopefully, it'll prevent Minix from nearly claiming someone else's sanity, like it almost did mine.

[Antoine LECA]

"John Doe" wrote:
> Wow, I had completely forgotten about this thread. The good news is I
> forgot in my joy of solving my problem. It turned out I had the wrong
> location for the version number change. There are two directories in Minix
> that are very similar: /usr/include/minix/config.h and
> /usr/src/include/minix/config.h. It seems that when you recompile the
> Minix kernel, it takes all the includes in the /usr/src/ directory and
> moves them to the /usr/ directory, then compiles from the /usr/src/

Yes. This is exactly what is doing the `make includes` part of the whole
process: making sure that the header files used by the compiler are the
intended ones, which should be stored in the src/ tree as all the
components of the operating system.
What is a bit special about includes is that unlike usual make, it does
not pay attention to the modified timestamp --because any touch on a
header file would trigger a recompile of all the libraries and programs,
which is not desirable-- but rather do a content comparison, and updates
the /usr/include variant to mirror the src/include source.

For the record, the various parts of the `make world` process are:
- mkfiles: make sure the "Makefile infrastructure files" then to be used
by the rest of the process are the intended ones
- etcfiles: update the configuration of the system
- includes: see above
- libraries: make sure the libraries are updated with respect to the
(perhaps updated) headers, and the new versions are installed
- dep-all/dependall: combines two actions: to build and keep up-to-date
the .depend files which lists the dependencies of each program or
library; and to actually compile all the programs
- install: put into the target system the new programs
- etcforce: do some post-installation reconfiguration

> For someone who is new to programming an operating system, this was a
> really subtle bug, especially since I've done a lot of other C/C++/Java
> programming and have never seen behavior like this in a system before.

On the other hand, it is actually logical if you consider the headers as
well are part of the source, and should be under source control.

In fact, if you are programming a library or a component (as opposed to
a end-user program), you will likely have a similar behaviour with the
public headers (which is describing the interface part) of your library.
What makes developing an operating system really different, is that
those headers change often, and any change here triggers a recompile of
the whole thing, so the process has to be strict.

> might be worth it for the devs to put a readme in the /usr/include/minix/
> directory that says something to the effect of, "This gets overwritten at
> compile time!"

I do not agree. What you are observing is true when you are changing the
operating system. But if you are merely using the system (for example,
compiling using pkgsrc, even developing new packages) you will use the
/usr/include headers all over the time; moreover, if they get changed
(updated) because of an intervening operating system fix, things will
continue to Do The Right Thing for my hypothetical package developer,
and I believe this is great.


Antoine