Jeremy Blackburn's Weblog

Oh no!

Turns out that Minix does not have support for semaphores or pthreads!

This is probably not a true “deal breaker”, but the time required in modifying the gserver concept to run without semaphores or threads is currently way beyond the time I have available.

The solution?

Port the Minix telnetd code to Linux and work from there.

Decision made: Minix it is.

The install was reasonably straight forward:

Burn a CD.
Stick said CD in tray.
Boot computer.
Follow on screen prompts.

In about an hour or so I had a working Minix install.

Unfortunately, it was completely lacking in the realm of network connectivity as the NIC was not recognized. In fact, the fxp driver told me explicitly that my card wasn’t supported!

After first determining that my NIC was an Intel PRO/100 with hardware revision 82557C (by setting VERBOSE to 1 in /usr/src/drivers/fxp/fxp.h), I then took a look at the source for the fxp driver located in /usr/src/drivers/fxp/fxp.c and noticed the following:


case FXP_REV_82557A: str= "82557A"; /* 0x01 */
fp->fxp_type= FT_82557;
break;
case FXP_REV_82557B: str= "82557B"; break; /* 0x02 */
case FXP_REV_82557C: str= "82557C"; break; /* 0x03 */


Looks to me like revisions B and C are explicitly not supported while A is. I figured I’d take a risk and modified the code thusly:


case FXP_REV_82557C: str="82557C"; /* 0x03 */
fp->fxp_type= FT_82557;
break;


Upon performing a make clean && make && make install and rebooting I had a network connection and all was well.

Now on to the actual task at hand: Making Minix green.

Today I managed to get an implementation of the green client/server model running under Linux.

I started from some proof of concept code that was written for Windows and the vast majority of the porting work was in translating Windows specific code to run on Linux.

There were three major “types” of code that had to be translated:

1. Threads
2. Semaphores
3. User Interface

The thread code was relatively simple to port. Because there wasn’t anything too fancy going on in the Windows code, I just had to modify some CreateThread() calls to use pthread_create().

The semaphore related code was likewise easy to port e.g. replacing WaitForSingleObject() with sem_wait() and substituting sem_post() for ReleaseSemaphore().

The user interface code changes were by far the most time consuming. In the Windows code, kbhit() and getch() were used to “pause” the client long enough to simulate a network disconnect. Unfortunately, kbhit() and getch() are not part of the C library on Linux and due to the manner in which Linux (and other Unix-like operating systems) handles terminal input/output the ensuing work around code has a strong odor of hack on it. On the other hand, these calls weren’t really necessary as a simple ctrl-c of the client will do far more than simulate a network disconnect: it will actually perform one.

Once the above were completed, I got my first taste of a working green application. Instead of the normal situation of the server viewing a client disconnect as an indication that server side processing should stop, the server continues processing and buffers any output that would normally be sent to the client. Upon client reconnect, the server dumps all the buffered output back to the client. It’s a beautiful thing.

I’m now firmly convinced that a framework and/or kernel modifications could be made to ease the conversion of standard client/server model applications to the green model, or even make the change transparent.

But first I have to get everything working in telnetd…

I’ve been wondering about the direction I should take with my research related to the Energy Efficient Internet project.

Ultimately, our goal is to reduce the amount of power consumed due to the internet connectivity of edge devices. I’m focusing on the software side of things. I.e. What can we do to make our code less reliant on a power hungry network connection? In particular, I’m attempting to implement a “green” client/server model on top of a real world network application.

Network applications that require user input tend to be idle for a large percentage of time and thus are good candidates for application of the green model. But which real world piece of software should we modify?

A character based remote terminal connection seemed the obvious choice. I have been considering ssh and telnet and I’ve reached a mixed set of conclusions:

ssh is a much better choice as there is no way that telnet will have any real adoption.
telnet is a much better choice because ssh is a very complex piece of code.

To further muddy the water, there have been questions raised as to the using Minix instead of Linux as the implementation target. I’m undecided on this.

On the one hand, Minix as a whole is much more straight forward and more academically oriented. It might be much easier to write a paper based on Minix code. Furthermore, I’m interested in how the network stack and operating system itself can be modified to be more energy conscious and the learning curve for that level of mucking about in the Linux kernel would be quite steep.

On the other hand, the Minix install base is next to nothing and would have no where near the splash value of something done in Linux. Linux is as real world as it gets. There are also already projects focused on other areas of making Linux green where we might be able to get adoption.

My gut tells me that the correct thing to do is to start working on telnetd in Minix immediately. Rationalizing this urge, I believe that starting with something very straight forward with the entire operating system documented in hardcover might make things move faster. I also think that if I write the code correctly, porting any Minix code to Linux will be a snap.

I’d like to write multiple papers during my two semesters, and I think that doing the above might leave me with time to get my head around ssh and if I’m really lucky a chance to take a look at the network stack in Minix.