Hi Brian,
I'm writing directly (and posting too) because my posts continue
to get stopped at the gate. I used the link you sent, (it's the same one
I originally used) and I can get in, change my preferences, I get all
posts, etc. No idea why I'm blacklisted ;(
Anyway, I pulled down HEAD, and I took to heart your suggestion to use
cpio everywhere, rather than have dual methods (cpio and tar). It
simplifies everything in the end, but requires a lot of changes. Some
nice things about cpio is it's portable, it does crc on every file in
the stream and piping is simple.
Here's what I've done so far:
o added two new handler files:
o udp-sender-cpio (server /usr/bin)
o udp-receiver-cpio (initrd /bin)
* these are simple sh wrapper scripts that are called by
udp-sender and udp-receiver respectively with --pipe, and with $dir as a
parameter. On the sending end udp-sender-cpio cd's to $dir, does a find,
piping the result through cpio, and out to be multicast. On the
receiving end, it cd's to $dir, then cpio checks crc on each file as it
is written to disk, saving it's exit status in a temp file that is then
checked in flamethrower_client, retrying as needed.
o removed tar from the build system, replacing with cpio.
o I've added a make.d stub to work via get_source
o I patch cpio Makefile to be static after ./configure runs
(this may not be the best way, but I'm unsure how best to compile it
against uclib, or if I should allow it to be dynamically linked
normally, pulling the needed libs over - could use your advice here)
o I've modified the busybox build config to disable tar and
enable cpio for the initial pre-and-boel_binaries casts. This BB ver of
cpio does not do crc, but I can live with it until the boel_binaries are
put into place so as to keep the initrd at a reasonable size. I may
suggest the addition of crc to the upstream BB applet developer as a
wishlist item. This new method will keep the boel_binaries as an
un-tarred and un-gzipped filesystem on the image server. This has the
added benefit of making adding/removing files easier for end users as
well.
o I've modified flamethrowerd, flamethrower, and the
flamethower_client
o I'm looking into creating better x86_64 support, and I could use
some suggestions as to the best way to do this. The problem I'm having
here is we have Appro servers we're using for testing, and they have the
AMD-8111 PCI chipset. I cannot get the boel kernel to find the HDs. It
*appears* this chipset is not available in the kernel config without
compiling a kernel explicitly for x86_64, or maybe I'm missing
something. Would it be good to have a complete x86_64
kernel/initrd/boel_binaries tree just for this processor type? And if
so, how best to incorporate this into everything? Plus, my focus and
desire is for multicasting everything. If you think these changes are
going to break other stuff, please let me know. Figuring out how things
work has been a great learning experience for me. The build mechanisms
(get_source, for instance) are cool.
* Should I possibly be doing all this stuff in a separate experimental
branch?
PS: I'm also experimenting with unionfs, to create composite virtual
image dirs that can incorporate a base image with one or more overrides
overlayed, so they can be cast as a single image.
SystemImager Rocks!
Regards,
Christopher Barry
Software Engineer
InfiniCon Systems
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Sisuite-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-users
