« Good thing we didn't do any theropy, Dave | Main | Go to hell, Costas »

You have nice hands, Dave

Ick. My last entry was an example of good formatting gone bad. jjc even warned me about it, but my fingers just acted by themselves (really, I swear, officer!) and submitted the entry anyway. This is the same entry, but with the formatting fixed.

I had to delete the last entry from the jjc database as well, so that it didn't show up on the web page. Urgghh...

Great quote in text talking about the history of /bin vs. /usr/bin vs. /usr/local vs. /opt:

Manuals for these programs are present for one funny reason: Steve Bourne ran a cron script that checked /usr/bin for new/updated programs each night. If there was no manual or the manual had not been updated, the binary was removed by the daemon.

We finally got the project name "oscar" at SourceForge. Mike from IBM is filling up the site today and tomorrow. Finally!!

I was suddenly hit by the urge to hear "Echos" by Pink Floyd. It's playing right now. Mmmm.....

My paper got rejected from SC2001. Bonk. From the reviews, it was apparently mainly because I didn't have any results in it (they only wanted an extended abstract -- full paper to be submitted later). I was right up against the word limit as it was, so I put a blurb in there about "results will be included in final paper". Both Lummy and I thought that would be ok for the extended abstract. Apparently not. <sigh>

Tracy and I built our new patio furniture in the rain yesterday. The furniture was delivered to our back patio during the day. Shortly after Tracy got home, it started raining. Oops -- all the furniture is still out there, and is in cardboard boxes! So we decided to just build it right then and there. When was the last time you built patio furniture in a thunderstorm?

Had more interesting discussions today with Brian about multi-threading LAM and the lamd (at least 2 hours worth). Good stuff, but very confusing. Wow. He did a good writeup of it in his journal.
Talked with Dog for a long time about what he's going to be doing in LAM, too. Very cool stuff. He's going to modularize some of the stuff in LAM that we use for bootup and various system services on different kinds of systems (regular rsh, scyld, tm, globus/grid, condor/grid, condor, etc.). We more or less figured out how to do it such that it can be entirely self-contained in its own module directory (e.g., modules/rsh or modules/scyld).

The most obvious example of where such things would be useful is for lambooting -- each different kind of system has different ways to launch executables on remote nodes. But there are other things as well -- Scyld's whole "there's little or no filesystem on the nodes" concept really threw Brian for a loop when he did the Scyld stuff, for example.

Here's the loose plan:

  • The idea is to aggressively build as many of the modules as possible. Hence, it tries to configure all of the modules. If the configuration of a given module fails (e.g., libbproc can't be found
    -- so we must not be on a Scyld system), we don't build it.

  • Additionally, the overriding goal here is that a module is completely self-contained in its directory -- the addition of a new directory requires no changes to any other part of LAM.

  • LAM's top-level ./configure will traverse the directories in modules/ and look for a configure script. If a directory has one, the top-level ./configure will run it.

  • If the configure script in that directory succeeds, the top-level ./configure will add it to the "to be built" list. If the configure script in that directory fails, that directory will be ignored.

  • For all modules listed in the "to be built" list, the top-level ./configure script creates a .c file (perhaps share/etc/modules_init.c) that is part LAM (in liblam.a somewhere) that initializes the modules. This .c's only purpose is to call the "init" function of each module. So some standard header is written out, followed by a list of "lam_module_NAME_init()" calls, where NAME is replaced with rsh, scyld, etc. (i.e., whatever the name of the module's directory is). This is because the function names cannot be the same, or we'll get linker errors. So instead, there is a naming convention so that we can build the function call list on the fly.

  • Indeed, the API that these modules will need to support will also not have function names (for the same linker error issues) -- the init function of each module will need to supply a struct full of function pointers of all the module functions.

  • Assumedly, LAM will have one or more modules built at compile time. Later, at run time, LAM must determine which module to use. One of the module functions (perhaps it will be the init function itself) will be used to make this decision. That is, keep the decision for whether that module should be run or not in the module itself -- the module can do whatever test it wants to determine if it should be run. For example, if the tm module detects the environment variable PBS_ENVIRONMENT, then the tm module should be used.

  • However, one can imagine situations where multiple modules may report "yes, I'm the module to use". So each module should probably also have a command line flag that forces its use to resolve ambiguities. For example, say you're running in PBS, but also happen to be in a Globus environment. In this case, you'll probably want to use the Globus module, not the tm module. However, both modules would probably report that they could be used. So we'll have a flag such as "-Mglobus" to lamboot that would tell all the modules "if you're name ain't 'globus', you ain't runnin'." But most of the time, there probably won't be an ambiguity, and the modules can just determine themselves which module to use (optimize the common case).

This is actually quite a useful concept. There's a few other details that I didn't mention (e.g., for all the API functions, there will also be "default" versions such that if a given module supplies a NULL function pointer for a given API call, the default version will be used instead -- somewhat like C++ base/virtual functions).

I love interpreted languages that have eval functionality. This allows you to effectively have self-generating code. I'm guessing that this is the entire premise of Spielberg's new "A.I." movie --
self-modifying php and perl scripts that went bad and ended up going to war with each other to prove language supremacy once and for all.

Let us not forget the following quote from the Field Guide to Your Unix Sysadmin:

Typical root .cshrc file:

TECHNICAL THUG: Longer than eight kilobytes. Sources the output of a perl script, rewrites itself.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on June 29, 2001 8:01 AM.

The previous post in this blog was Good thing we didn't do any theropy, Dave.

The next post in this blog is Go to hell, Costas.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34