Hi William. Thanks for your quick response. My response inline.
On 11/26/08 10:46, William Schumann wrote: > Jack, > > Jack Schwartz wrote: >> Hi William. >> >> I wanted to talk with you as you are the expert about what is needed >> as far as install module updates for SPARC. > Jan and I met this afternoon and we think we have the Orchestrator, > TD, and TI covered. OK. > >> I've seen emails between Jan and Angela Li which say that libti is >> current for SPARC, but I am wondering about libtm and the target >> discovery module. My hunch is that libtm should just work, as all it >> does is move files, right? ... or is there more to it than that? > Jack, by libtm, are you referring to libtransfer - TM? It sounds like > it, and yes, it pretty much just moves files with standard utilities, > but I'll go back over the code to make sure. OK. > > I've been looking over the new disk partitioning features of the AI > engine, and submitted a sparc-related enhancement request earlier today: > http://defect.opensolaris.org/bz/show_bug.cgi?id=5451 OK. Which module will this change go? Below you say that TD won't require any changes, but this bug looks like it deals with disk selection. Is this different than discovery? > > AI engine code will have to be made to skip over fdisk partitioning > calls, including its calls to TI. >> As I understand, target discovery module needs tweeks as there is no >> equivalent to fdisk on SPARC. Is there more that is needed? > TD has worked on Nevada and is pretty much the same today - I don't > think TD will require any changes at all. OK. I see that fdisk is called by libti, not TD. >> >> Not sure if I'll get to talk to you today. Regardless, please begin >> implementing the needful for these modules. Since DC needs the >> transfer module, please work on that first if work is needed. > DC definitely needs TI, but I'm not sure how it uses transfer module - > I thought that the transfer module was more for putting the > distribution on the target disk and didn't use DC directly. Or do I > need to revisit the design doc? DC uses TM to move bits into the pkg_image area (a.k.a. proto area) and into various lofi-mounted archives. It uses IPS mode to populate the pkg_image area and cpio mode for the rest. I thought I'd heard that TM needed to be changed, though I didn't understand why (since I, too, thought that all it did was move bits). With the exception of setup (making sure directories exist, are purged, etc) that's what the code (usr/src/lib/libtransfer/transfer_mod.py) shows. > Anyhow, The DC part of TI should be platform-independent. Agreed. >> I'm sure the DC team will make use of your help next week after >> Thanksgiving to debug getting a SPARC image built. OK, so if TI and TM don't change for SPARC, then I think DC is good to go. DC is the next thing which has to happen in the progression toward SPARC support. >> >> By the way, there is now a SPARC repo as of this morning (Yay!). >> http://ipkg.sfbay:29048 (internal only) > That's some good news. > I resumed testing of > http://defect.opensolaris.org/bz/show_bug.cgi?id=4233 today, which has > been marked as critical for the SPARC release. I think that this is > ready to go. OK, Thanks. > > I'm really happy that you are taking proactive steps in organizing > people to get people to think of all the details so there will be few > oversights toward the end. Thanks. I'm endeavoring to put all the building blocks together. Sounds like both you and Jan have stuff to work on for AI. It's possible that Karen or Jean may be contacting you if they find issues with DC, but I doubt it. Thanks, Jack
