Hi everyone.
After thinking through this some more and more discussion with Ethan, I
have decided a better solution would be to do the AI manifest access
using the same C functions the rest of AI already uses. This will be
cleaner and more consistent (and thus more maintainable and easier to
understand). My module will also contain bridges to call DDU python
functions directly (similar to what the ddu_call.py module did in my
original proposal). It's a little more work for me, but in the end will
be worthwhile IMO.
Thanks,
Jack
On 01/19/10 09:04, Jack Schwartz wrote:
> Hi Ethan.
>
> Thanks for your feedback.
>
> My responses inline.
>
> On 01/19/10 07:48, Ethan Quach wrote:
>> Jack,
>>
>> Seems okay. Just a couple of nits/questions below ...
>>
>> Jack Schwartz wrote:
>>>
>>> Hi Ethan.
>>>
>>> After talking with you, I looked at how I could refactor AI as
>>> minimally as possible to that I can make room for Driver Update. I
>>> wanted to keep the look of the current modular structure, and came
>>> up with the following.
>>>
>>> 1) ddu_call.py: (new) This is AI's python module that calls into the
>>> DDU library module proper. We talked about making this general, but
>>> most of the code in the module deals with reading the AI manifest,
>>> so I think it is best to dedicate this module to AI. (The
>>> text-installer can write its own analogous module, which will be
>>> mostly different anyway, when the time comes.
>>>
>>> 2) auto_ddu_lib.c : (new) AI-specific C library that calls into the
>>> ddu_call.py module. Having this module will remove ddu calls from
>>> any module which deals with parsing (auto_parse_manifest.c and
>>> auto_parse.c). It will have two routines:
>>> - ai_get_and_add_du_pkgs(): reads the AI manifest and installs
>>> into the given environent. (It will be passed the booted
>>> environment as an arg.) Saves the package list.
>>> - ai_add_du_pkgs(): installs into the given environment. Uses
>>> package list created by ai_get_and_add_du_pkgs(). (It will be
>>> passed the target as an arg.)
>>
>> Any reason why these wouldn't be split as:
>> - ai_get_du_pkgs()
>> - ai_add_du_pkgs()
>>
>> or is the intent for the main AI code not to have to handle
>> the ddu package list?
> Yes, that is the intent. This makes the AI C-python bridge code cleaner.
>>
>>>
>>> 3) auto_parse_manifest.c splits the existing
>>> ai_create_manifestserv() into two functions:
>>> - a new ai_create_manifestserv() which just instantiates the
>>> manifest tree but doesn't check it. (We can't check it until we've
>>> done driver_update, and we need the manifest to do driver_update.)
>>> - ai_setup_manifestserv() which does validation and setup of the
>>> socket server.
>>> NOTE: As part of this work, I split ManifestServ out so that
>>> instantiating a ManifestServ object no longer does validation.
>>> ai_create_manifestserv() still instantiates as before, but now
>>> ai_setup_manifestserv() invokes the ManifestServ object's validation
>>> code.
>>>
>>> 4) auto_parse.c/ai_validate_and_setup_manifest() will be refactored
>>> into ai_create_manifest() and ai_setup_manifest(). These will
>>> simply call into auto_parse_manifest.c/ai_create_manifestserv() and
>>> ai_setup_manifestserv(). These are kept to preserve the calling
>>> structure between auto_parse.c and auto_parse_manifest.c
>>>
>>> 5) auto_install/main() will make the following calls, in order:
>>> ai_create_manifest()
>>> ai_get_and_add_du_pkgs()
>>> ai_setup_manifest()
>>> dump_ai_manifest_errors()
>>>
>>> 6) auto_install/auto_perform_install: will call
>>> ai_add_du_pkgs()
>>> after spinning waiting for om_perform_install() to finish.
>>>
>>> Comments welcome.
>>>
>>> Thanks,
>>> Jack
>>>
>>> P.S. Not sure what I would need to do extra, if anything, to enable
>>> testing of AI with driver update (in terms of how AI's commandline
>>> options which deal with testing are implemented). Please advise.
>>
>> When -d is given, a manifest isn't even used. The test path
>> in the code hardcodes in dummy values for everything else
>> needed (I'm sure that was useful at one point) so wrt to ddu,
>> it doesn't seem that a disk given with -d can require a du. And
>> I think it'd require major rework of this code to enable that,
>> which I don't think is a requirement for the ddu work. The way
>> the -d behaves, it seems processing a manifest at all is adverse
>> to what's its designed to provide.
>>
>> The -i and -I options set breaks around the TI step, which is
>> past, anything you're changing, so these should continue to
>> work, as test options, with du processing.
>>
>> -ethan
>>
> After talking in person, I learned that the testing options of AI
> aren't used anymore. Testing of Driver Update with AI can be done by
> executing it the way it is normally used, via the manifest.
>
> Thanks,
> Jack
