etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Etherboot 5.1.4rc1 (development) released

[<ebi...@ln...>]

ke...@us... writes:

> I've checked in a bunch of changes. You can get the latest state of play
> from CVS or from http://www.etherboot.org/etherboot-5.1.4rc1.tar.bz2
> 
> Notably the lz targets are now gone.  For lz, substitute nrv2b
> everywhere, e.g. make bin/3c509.nrv2brom.  I have confirmed that
> nrv2brom, nrv2bdsk (and hence nrv2bfd0) work. It would be nice if
> someone could confirm: pxe, nrv2bpxe, lilo, nrv2blilo and com.

Think we might want to find a shorter suffix than nrv2b?  Say just
'z'.

nrv2b is quiet descriptive and unique but it I think its length may
get a little cumbersome.  And if we only have one compression
algorithm we have no need to distinguish between the two.

Eric

Re: [Etherboot-developers] Question on relocation etc..

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Ken posted a message about updates required to the drivers for the 5.1
> >branch for relocation.  Can someone expand on the details for me?  I am
> >developing the driver based on a cvs update pre Eric's directories
> >restructure.  Is there something special that needs to be done for 5.1
> >because of relocation?
> 
> Eric will correct my mistakes when he gets back but I believe the story
> is like this:

I am not quite back but this is a good question that need to get documented.

> 
> Etherboot runs at virtual address 0x20000 upwards (see
> arch/i386/Makefile). However this actually corresponds to a physical
> address somewhere at the top of memory due to address translation.
> 
> Within Etherboot itself there is no problem using the virtual addresses,
> memory references will come out ok.
> 
> However when you give the address to hardware, say for DMA or something,
> you have to convert them to physical addresses or the hardware will try
> to access the wrong locations. The function virt_to_phys or virt_to_bus
> (same thing) will do this for you.

Only the same on x86.  Other architectures may have a difference 
bus and physical addresses.  Though I can't see why they would.
Drivers should not need to use physical addressees.

virt_to_bus, and bus_to_virt, and ioremap are all drivers should need
to use.

> In some cases you have to call the reverse function phys_to_virt, when
> the hardware contains shared memory, e.g. WD8013 NICs, so that Etherboot
> will address the correct hardware address. Typically this is in places
> where you load address registers of the NIC.

I believe this is where you need ioremap.  virt_to_bus should
only be valid for memory used in etherboot.  bus_to_virt is simply
the inverse function of virt_to_bus.  ioremap works on arbitrary
device shared memory.  The e1000 and FA311 drivers have used ioremap.

Eric

Re: [Etherboot-developers] rom-o-matic.net upgrades, Etherboot testers wanted!

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >formats, except LinuxBIOS. So I'd especially appreciate some LinuxBIOS 
> >folks verifying that 5.1.3 generates something usable. I'm not sure 
> >which drivers are LinuxBIOS ready in 5.1.3, but I'd enjoy finding out.  

I will double check in a bit.

All etherboot drivers should work under LinuxBIOS.  The only thing
you can't test is linuxbios.c For the rest under LinuxBIOS the code
is compiled with CONFIG_TSC_CURRTICKS.   As we cannot use the BIOS
timer.  But that should be quite normal.

> Eric can correct me here, but IIRC it should be the same drivers that
> are relocation-ready. Anything fixed by Eric is ready, e.g. eepro100,
> e1000. Anything that uses IO only is ready, e.g. 3c509, NE2000, cs89x0.
> Anything that hasn't had the virt_to_bus removed from the original Linux
> driver should have a good chance of working. I think natsemi, via-rhine,
> tulip and wd89c940 have a chance.

I am picky about being able to load arbitrary images, but the relocation
code is not strictly necessary for running under LinuxBIOS.

> Those I know are definitely not relocation-ready are rtl8139 and wd8013
> (this needs phys_to_virt I believe). I'll have a go at these soonish.
bus_to_virt?   

> >I'd kind of like to demo Etherboot with LinuxBIOS at LinuxWorld Expo, 
> >so maybe I'll find out what kind of motherboard to get and how to flash 
> >it, etc. (suggestions welcome, btw ;)  I'd also enjoy doing Etherboot 

With a little luck I might be able to help with a demo, but I run
pretty high end machines so on the low end I don't have any advise. 

Eric

Re: [Etherboot-developers] 5.1: virt_to_bus

[<ebi...@ln...>]

ke...@us... writes:

> Eric, I'm going to have a go at reintroducing virt_to_bus in some
> drivers. I gather I should use virt_to_bus whenever a hardware register
> is loaded with an address. That is, I should do:
> 
> 	outl(virt_to_bus(buffer), ioaddr+...);
> 
> but
> 
> 	memcpy(nic->packet, buffer, len);
> 
> and
> 
> 	buffer[i] = '\0';
> 
> remain unchanged?

Correct.

There are 3 types of addresses.
virtual address that ``&'' returns.
physical address that refer to different memory from the cpus perspective.
bus addresses that refer to memory from the devices perspective.

On x86 we currently only have distinct virtual addresses and
physical/bus addresses.  Keeping the distinction between physical
and bus addresses, while not strictly necessary makes portability
much easier.

In summary address that are sent to devices should be the result
of virt_to_bus.  Just about everything else can be left as is.

Eric

RE: [Etherboot-developers] Question on relocation etc..

[Timothy L. <tl...@ro...>]

> In some cases you have to call the reverse function phys_to_virt, when
> the hardware contains shared memory, e.g. WD8013 NICs, so that
Etherboot
> will address the correct hardware address. Typically this is in places
> where you load address registers of the NIC.

Thanks Ken.  It is amazing how little I know about this...

>Now I just need to track down a 14 missing bytes in my truncated
>transmit.  Is it possible that it is relocation related?

> Sounds like you forgot to fill in the Ethernet frame header?

You are probably correct.  When the server actually picked up the
broadcast from the card, I decided it was enough for one day...

Tim

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Etherboot-developers mailing list
Eth...@li...
https://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] Etherboot 5.1.4rc1 (development) released

[<ke...@us...>]

I've checked in a bunch of changes. You can get the latest state of play
from CVS or from http://www.etherboot.org/etherboot-5.1.4rc1.tar.bz2

Notably the lz targets are now gone.  For lz, substitute nrv2b
everywhere, e.g. make bin/3c509.nrv2brom.  I have confirmed that
nrv2brom, nrv2bdsk (and hence nrv2bfd0) work. It would be nice if
someone could confirm: pxe, nrv2bpxe, lilo, nrv2blilo and com.

Re: [Etherboot-developers] Question on relocation etc..

[<ke...@us...>]

>Ken posted a message about updates required to the drivers for the 5.1
>branch for relocation.  Can someone expand on the details for me?  I am
>developing the driver based on a cvs update pre Eric's directories
>restructure.  Is there something special that needs to be done for 5.1
>because of relocation?

Eric will correct my mistakes when he gets back but I believe the story
is like this:

Etherboot runs at virtual address 0x20000 upwards (see
arch/i386/Makefile). However this actually corresponds to a physical
address somewhere at the top of memory due to address translation.

Within Etherboot itself there is no problem using the virtual addresses,
memory references will come out ok.

However when you give the address to hardware, say for DMA or something,
you have to convert them to physical addresses or the hardware will try
to access the wrong locations. The function virt_to_phys or virt_to_bus
(same thing) will do this for you.

In some cases you have to call the reverse function phys_to_virt, when
the hardware contains shared memory, e.g. WD8013 NICs, so that Etherboot
will address the correct hardware address. Typically this is in places
where you load address registers of the NIC.

>Now I just need to track down a 14 missing bytes in my truncated
>transmit.  Is it possible that it is relocation related?

Sounds like you forgot to fill in the Ethernet frame header?

[Etherboot-developers] Question on relocation etc..

[Timothy L. <tl...@ro...>]

Hi

I am working on my sundance driver for the DFE-530TXS and others.  This
evening, I managed to get it to transmit something, so I thought I
should get some info about relocation etc.

Ken posted a message about updates required to the drivers for the 5.1
branch for relocation.  Can someone expand on the details for me?  I am
developing the driver based on a cvs update pre Eric's directories
restructure.  Is there something special that needs to be done for 5.1
because of relocation?

Now I just need to track down a 14 missing bytes in my truncated
transmit.  Is it possible that it is relocation related?

Regards

Tim

[Etherboot-developers] 5.1: CVSed rtl8139.c, ns8390.c, eepro.c

[<ke...@us...>]

Ok, I've CVSed changes to these drivers for relocation. They are totally
untested. But I'd be particularly interested to know if the rtl8139
driver works now, as it's a very common chip.

I'm off to the beach now, see you. :-)

[Etherboot-developers] removing drivers in 5.1

[<ke...@us...>]

I've killed the following drivers in 5.1 CVS:

ni5010, tiara, i82586 (ni5210, exos205, 3c507)

If you have any of these ancient ISA NICs and it actually works for you
in 5.0, come around to my place to demonstrate it and I'll give you a
decent 3c509 in exchange. :-)

Re: [Etherboot-developers] rom-o-matic.net upgrades, Etherboot testers wanted!

[<ke...@us...>]

>formats, except LinuxBIOS. So I'd especially appreciate some LinuxBIOS 
>folks verifying that 5.1.3 generates something usable. I'm not sure 
>which drivers are LinuxBIOS ready in 5.1.3, but I'd enjoy finding out.  

Eric can correct me here, but IIRC it should be the same drivers that
are relocation-ready. Anything fixed by Eric is ready, e.g. eepro100,
e1000. Anything that uses IO only is ready, e.g. 3c509, NE2000, cs89x0.
Anything that hasn't had the virt_to_bus removed from the original Linux
driver should have a good chance of working. I think natsemi, via-rhine,
tulip and wd89c940 have a chance.

Those I know are definitely not relocation-ready are rtl8139 and wd8013
(this needs phys_to_virt I believe). I'll have a go at these soonish.

>I'd kind of like to demo Etherboot with LinuxBIOS at LinuxWorld Expo, 
>so maybe I'll find out what kind of motherboard to get and how to flash 
>it, etc. (suggestions welcome, btw ;)  I'd also enjoy doing Etherboot 
>with Grub demos. Anybody got that set up and can email me an 
>explanation of how you do it?

I think GRUB will handle .lilo images just like that, I recall seeing
someone posting that it works.

[Etherboot-developers] rom-o-matic.net upgrades, Etherboot testers wanted!

[Marty C. <md...@et...>]

Ah, the holidays, a time to relax, to enjoy a little time off, a time 
to upgrade hardware and install new distributions... ;)

I've upgraded rom-o-matic.net to RedHat 8.0 to take advantage of GCC 
3.2 and various fixes. I've also changed the motherboard and CPU from a 
PIII 600 to a PIII 1.1GHZ, which has shaved about 25% from the image 
generation times.  Of course that only means 3.5 seconds instead of 4.5 
seconds for 5.0.8, and 4.5 instead of 7.5 for 5.1.3, but when you're 
sitting in a web browser, 5 seconds can seem like an eternity. 3.5 
feels better :)

Anyway, I'd appreciate some systematic testing. I can test almost all 
formats, except LinuxBIOS. So I'd especially appreciate some LinuxBIOS 
folks verifying that 5.1.3 generates something usable. I'm not sure 
which drivers are LinuxBIOS ready in 5.1.3, but I'd enjoy finding out.  
I'd kind of like to demo Etherboot with LinuxBIOS at LinuxWorld Expo, 
so maybe I'll find out what kind of motherboard to get and how to flash 
it, etc. (suggestions welcome, btw ;)  I'd also enjoy doing Etherboot 
with Grub demos. Anybody got that set up and can email me an 
explanation of how you do it?

So, if you've got some time (hardware :) and the inclination, could you 
do something like:
           ROM          (worked/failed)   (worked/failed)
NIC       Format       Result (5.0.8)    Result (5.1.3)
           .lzdsk
           .lzrom
           .lzlilo
           .lzpxe
           .com
           .elf


Now, it would be cool if the same person could test all these formats, 
but if enough people test, I'm sure we can fill in the matrix.  Default 
Etherboot options are fine.

So, who's up for some testing?  We'll sure appreciate your time and 
your data.
Send email to Etherboot-users with your results, and you can also fill 
out an entry at: http://www.etherboot.org/db/

Thanks a lot!

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
   Voice: (617) 491-6935; Fax: (617) 491-7046
   Email: md...@et...
     Web: http://www.etherboot.org/

[Etherboot-developers] 5.1: virt_to_bus

[<ke...@us...>]

Eric, I'm going to have a go at reintroducing virt_to_bus in some
drivers. I gather I should use virt_to_bus whenever a hardware register
is loaded with an address. That is, I should do:

	outl(virt_to_bus(buffer), ioaddr+...);

but

	memcpy(nic->packet, buffer, len);

and

	buffer[i] = '\0';

remain unchanged?

[Etherboot-developers] changes to 5.1 in CVS

[<ke...@us...>]

I've done the following to the CVS of 5.1:

Removed the USE_LOWMEM_BUFFER option. Should no longer be necessary
in 5.1 anyway.

Removed otulip.[ch]. I don't think it's maintainable anyway.

Re: [Etherboot-developers] Makefile suggestion

[<ke...@us...>]

>I was thinking that in the "make clean" stanza of Makefile, we might 
>want to add Roms, since it is generated from NIC using genrules.pl.
>
>So we would have:
>
>clean:
>	$(RM) $(UTILS) bin/*.s bin/*.o bin/*.bin Roms

I think you're right, it's better to regenerate Roms everytime. It seems
to work ok with the current Makefile after regeneration.

[Etherboot-developers] Makefile suggestion

[Marty C. <md...@et...>]

Hello All,

I was debugging some Makefile stuff ran into an interesting bug where 
the Roms file was not getting rebuilt based on changes to genrules.pl. 
My reading of the Makefile suggests that it should, but it wasn't.

I was thinking that in the "make clean" stanza of Makefile, we might 
want to add Roms, since it is generated from NIC using genrules.pl.

So we would have:

clean:
	$(RM) $(UTILS) bin/*.s bin/*.o bin/*.bin Roms

I think what might have happened is that I accidentally edited Roms 
after editing genrules.pl (but before I did a "make"), so genrules.pl 
was not run to regenerate Roms, which made the Makefile not work as 
expected.  Once I deleted Roms, it got regenerated.  I'm also thinking 
we might not want to distribute a pre-built Roms file with the 
distribution, so that it gets made when it is needed. Frankly, since 
Roms is Included in Makefile, I'm wondering whether "make" can sanely 
check Roms before it is Included.

I suppose this would necessitate people having Perl, so that is a 
consideration, but it is pretty common these days.

Food for thought. What do you think? I'm sure we have some Makefile 
wizards out there, since the $rom--% rules got in there ;)

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
   Voice: (617) 491-6935; Fax: (617) 491-7046
   Email: md...@et...
     Web: http://www.etherboot.org/

[Etherboot-developers] [Commit] Prism2a diff update.

[Boris R. <bo...@bo...>]

Ok, I took out all my other changes(spinlock and some error checking) but
just kept the prism_reset function. I had this problem that once I turn on
the computer and the system boots off the floppy, everything is alright. It
seems that after a few reboots after being on for a few days, The card
cannot be initialized anymore. The only cure was to turn off and then turn
on the computer. I read in the linux-wlan changelog about a surious
interrupt problem which I thought the spinlock function would fix it. Since
I added the spinlock code, I havent had that problem again so thats why I
added it into my patch. I will still have to check if the problem still
exists with *only* the reset function. Here is a new .diff update.

Boris Reisig (bo...@bo...)
Sent: Sunday, December 22, 2002 4:35 PM
Subject: Re: [Etherboot-developers] [Commit] Prism2 CVS Update.


> >Hello, This is my first .diff patch based from the latest etherboot
5.0.xx
> >cvs. This updates the prism2 driver to the latest linux-wlan 0.1.16pre8.
> >
> >- This should enable a workaround for spurious interrupts generated
before
> >initialization
> >    is complete.(I had problems with)
> >- Some more error checking.
> >
> >Can anyone take a look at it for any errors? I would like to get it
> >submitted into cvs.
>
> Hope Michael is reading this. I think the spinlock code isn't needed
> because there is only one process running, but if it doesn't cause
> problems, as it doesn't use up much space it might be good to retain a
> resemblance to the original Linux driver.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] [Commit] Prism2 CVS Update.

[Michael B. <mb...@fe...>]

On Mon, 23 Dec 2002, Ken Yap wrote:
> >Hello, This is my first .diff patch based from the latest etherboot 5.0.xx
> >cvs. This updates the prism2 driver to the latest linux-wlan 0.1.16pre8.
> >- This should enable a workaround for spurious interrupts generated before
> >initialization
> >    is complete.(I had problems with)
> >- Some more error checking.
> >Can anyone take a look at it for any errors? I would like to get it
> >submitted into cvs.
> Hope Michael is reading this. I think the spinlock code isn't needed
> because there is only one process running, but if it doesn't cause
> problems, as it doesn't use up much space it might be good to retain a
> resemblance to the original Linux driver.

Have reviewed.  Most looks fine.  The structure of the Etherboot driver is
that the .h files are lifted straight from linux-wlan-ng, while the .c
files are reverse-engineered from it.  All changes to the .h files are
therefore fine, assuming that they merely update the files to match the
latest linux-wlan-ng.

The spinlock code should not be there.  The Etherboot code in prism2.c is
different enough from the Linux driver that it is not worth retaining
extra code that has no practical purpose.  I therefore recommend rejecting
all changes to prism2.c except for the addition of prism2_reset.  There is
another problem: the prototype of prism2_reset in the patch is incorrect.
This will have to be slightly reworked.

In summary: feel free to commit changes to the header files, hold off on
the changes to prism2.c.  I will edit the patch and check in the changes
to prism2.c some time after Christmas: someone please remind me if I
haven't done it by New Year's Day.

I'm unlikely to read any replies in the next week or so, so please don't
think I'm being rude and ignoring them!

Merry Christmas to all.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] [Commit] Prism2 CVS Update.

[<ke...@us...>]

>Hello, This is my first .diff patch based from the latest etherboot 5.0.xx
>cvs. This updates the prism2 driver to the latest linux-wlan 0.1.16pre8.
>
>- This should enable a workaround for spurious interrupts generated before
>initialization
>    is complete.(I had problems with)
>- Some more error checking.
>
>Can anyone take a look at it for any errors? I would like to get it
>submitted into cvs.

Hope Michael is reading this. I think the spinlock code isn't needed
because there is only one process running, but if it doesn't cause
problems, as it doesn't use up much space it might be good to retain a
resemblance to the original Linux driver.

[Etherboot-developers] [Commit] Prism2 CVS Update.

[Boris R. <bo...@bo...>]

Hello, This is my first .diff patch based from the latest etherboot 5.0.xx
cvs. This updates the prism2 driver to the latest linux-wlan 0.1.16pre8.

- This should enable a workaround for spurious interrupts generated before
initialization
    is complete.(I had problems with)
- Some more error checking.

Can anyone take a look at it for any errors? I would like to get it
submitted into cvs.

Boris Reisig

Re: [Etherboot-developers] Can EtherBoot be compiled into an executable file?

[<ebi...@ln...>]

"Eddy" <ed...@si...> writes:

> There are several options about output format in the Config file, including
> ROM,LILO,etc.
> 
> I wonder if it is possible to compile it into an executable fle so I can run:
> ./etherboot
> to boot a remote linux/windows...

Under which OS, on which architecture?

> If that can be realized,it would be great! Of course,we need to switch into real
> mode first...
> 
> 
> In my opinion,it should be not too difficult...
> Anyone has a clue?

kexec ./etherboot.elf 

works with the appropriate patch to 2.5.

Eric

Re: [Etherboot-developers] Can EtherBoot be compiled into an executable file?

[Anselm M. H. <an...@ho...>]

Hello Eddy,

Sunday, December 22, 2002, 4:03:46 PM, you wrote:

E> There are several options about output format in the Config file, including ROM,LILO,etc.
E> I wonder if it is possible to compile it into an executable fle so I can run:
E> ./etherboot
E> to boot a remote linux/windows...
E> If that can be realized,it would be great! Of course,we need to switch into real mode first...

Dunno if it's to great...
If you want to testdrive network-booting, probably having a separate
test-machine would help you better. Or you could pay $$$ for vmware...
Perhaps even a lilo bootloader entry "Etherboot" would help you, which
works for me like a charm.

For lilo-loading etherboot, get a .lzlilo or .lilo image from
rom-o-matic, enter it into /etc/lilo.conf (after RTFM, of course) and
"lilo". Next start you should be presented a choice to load etherboot.

E> In my opinion,it should be not too difficult...
E> Anyone has a clue?

I'm not to sure it's a nice idea to switch to real mode. First, you
should unload all filesystems and daemons and stuff, like for a
reboot. What does it matter to run through the bios once more? That's
mostly a question of seconds, with no extra difficulties at all.

Don't forget that's my 0,02 Euro not more.
Do what you please, it's interesting anyway :-)

Best regards,
 Anselm                            mailto:an...@ho...

[Etherboot-developers] Can EtherBoot be compiled into an executable file?

[Eddy <ed...@si...>]

VGhlcmUgYXJlIHNldmVyYWwgb3B0aW9ucyBhYm91dCBvdXRwdXQgZm9ybWF0IGluIHRoZSBDb25m
aWcgZmlsZSwgaW5jbHVkaW5nIFJPTSxMSUxPLGV0Yy4NCkkgd29uZGVyIGlmIGl0IGlzIHBvc3Np
YmxlIHRvIGNvbXBpbGUgaXQgaW50byBhbiBleGVjdXRhYmxlIGZsZSBzbyBJIGNhbiBydW46DQou
L2V0aGVyYm9vdA0KdG8gYm9vdCBhIHJlbW90ZSBsaW51eC93aW5kb3dzLi4uDQpJZiB0aGF0IGNh
biBiZSByZWFsaXplZCxpdCB3b3VsZCBiZSBncmVhdCEgT2YgY291cnNlLHdlIG5lZWQgdG8gc3dp
dGNoIGludG8gcmVhbCBtb2RlIGZpcnN0Li4uDQoNCkluIG15IG9waW5pb24saXQgc2hvdWxkIGJl
IG5vdCB0b28gZGlmZmljdWx0Li4uDQpBbnlvbmUgaGFzIGEgY2x1ZT8NCg0K

Re: [Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

[<ke...@us...>]

>The code is commited.  I just call finalise_image just before we
>close(STDOUT).  It is the last thing and that is a very reasonable
>place to put.
>
>Later.  I am off for the Christmas holidays.  When I get back I will
>finish up, the itanium stuff, think about hammer, and get ready for LinuxWorl
>d..

The stuff rocks, thanks. I'll give the stuff the once over and release
1.2-12 before the new year. Maybe a 5.1.4 tarball for bleeding edge
enthusiasts and Marty "rom-o-matic" Connor, who will hate me. :-)

Enjoy your holidays.  Hope you drop in on the Etherboot and LTSP booths
at Linuxworld, I'm sure you'll be a most welcome guest there.

Re: [Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >I have answered this, and the design was o.k. But you
> >never called finalise_image().  Once that was fixed I could buffer the
> >entire image in memory and then poke the note section when I was done.
> 
> Ah, I wasn't sure where you wanted to call it. Last thing in the routine
> that handles the format?

The code is commited.  I just call finalise_image just before we
close(STDOUT).  It is the last thing and that is a very reasonable
place to put.

Later.  I am off for the Christmas holidays.  When I get back I will
finish up, the itanium stuff, think about hammer, and get ready for LinuxWorld..

Eric