Sundar Yamunachari wrote: > Jean McCormack wrote: >> Sundar Yamunachari wrote: >>> Jean McCormack wrote: >>>> Dave Miner wrote: >>>>> Jean McCormack wrote: >>>>>> I have posted the functional specification for the Install >>>>>> support for extended partitions and slice modification at: >>>>>> >>>>>> http://www.opensolaris.org/os/project/caiman/Extended_Partition_Support/EP_Func_Spec.txt/ >>>>>> >>>>>> >>>>>> >>>>> >>>>> I presume that should be EP_Func_Spec.odt? >>>>> >>>>> Dave >>>> It is now. I replaced it this morning with the .odt. >>>> >>>> Jean >>>> _______________________________________________ >>>> caiman-discuss mailing list >>>> caiman-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> Jean, >>> >>> General: minor nit: section numbers are not consistent through out >>> the document >>> >>> 1.1 Scope of the problem >>> >>> - Are you planning to change libti (which does the actual partition >>> and slice modification work)? or the changes will be in >>> liborchestrator? >> I've been thinking about this more and more and want to add onto my >> response. The base changes for slice modification will take place in >> liborchestrator because that's the code that the UI uses. However, >> I'm bothered by the fact that it appears we have the same or similar >> code in liborchestrator and libti. For the completeness phase of the >> slice modification work the plan is to move the code from >> liborchestrator to libti or some TBD library. I think that when this >> is being done, the libti code you reference needs to be looked at and >> we should try to make 1 piece of code that AI and everyone else uses >> to do the partition and slice modification. > I had similar concerns. The library libti supposed to do all the disk > creation/modification stuff and liborchestrator supposed to provide > the data. If you are not changing libti for extended partitions, I > thought that the existing code in libti is sufficient. Thanks for the > clarifications. Just to be clear, liborchestrator does call libti to do the hard core creating. i.e. the call to fdisk. So this work may just turn out to be making sure the code supporting code isn't duplicated.
Jean > > - Sundar >> >> Jean >> >> >> >>> - You mentioned GUI support is part of the scope. Is GUI changes >>> part of this project? >>> >>> 1.2 Interdependencies >>> - AI also depends on the changes to TD, TI and Orchestrator >>> >>> 2.1 Major components >>> - Will there be any changes in libti? >>> >>> >>> 2.3 Test Environments >>> - If there are no changes made by this project to AI, what kinds of >>> tests will be performed with AI? Is it regression testing to make >>> sure that existing things still work? >>> >>> 3 User interface >>> - I don't understand the terminology. Is it logical disks or logical >>> partitions? >>> >>> 1.1 libdiskmgt support >>> - AI uses FD_NUMPART in couple of places. As longs as FD_NUMPART is >>> updated to correctly, we should be ok. >>> >>> >>> 1.2 Scenario Two >>> - Which module creates the logical partition? Is it Orchestrator or >>> libti? >>> >>> >>> - Sundar >>> >> >
