On 07/30/09 14:21, Dave Miner wrote:
> Jack Schwartz wrote:
>> Hi Dave.
>>
>> Thanks for your comments.
>>
>> On 07/30/09 10:01, Dave Miner wrote:
>>> Jack Schwartz wrote:
>>>> Hi everyone.
>>>>
>>>> The Driver Update Use Case document has been uploaded to:
>>>> http://www.opensolaris.org/os/project/caiman/Driver_Update/use-case-summary.latest.txt
>>>>
>>>>
>>>>
>>>> This describes how Driver Update additions would look from a user
>>>> point of view, for live CD GUI, text installer, and AI.
>>>>
>>>> This has already gone through a few iterations with Frank and
>>>> others, and should be fairly complete, so it should be pretty solid.
>>>>
>>>> Please send comments or questions over the next couple of days, if
>>>> any.
>>>>
>>>
>>> The solution described in use case 1 is rather un-GUI-like. I'd
>>> suggest discussing this with Frank, and considering more of a
>>> wizard-style design. Or perhaps that's what you're trying to
>>> describe, and the terminology just doesn't jibe.
>> Actually, Frank and I have already discussed this at length. We want
>> to build on what the DDU GUI looks like today. The "add-drivers"
>> mode does this. The menu selections which already exist today
>> (install all missing drivers, install for a specific device) can be
>> the same buttons which exist today. New selections can have new
>> buttons, and text fields can be popped up as needed for package and
>> (repo) location entry.
>>
>> The "silent mode" will make use of a pop-up notification, and will
>> allow the user to enter the "add-drivers" mode.
>>
>> Was there something specific which came across as un-GUI-like?
>
> "Looping through menus" sounds decidedly un-GUI-like to me. For this
> document, it might be best for you to refrain from that level of
> description and let the design cover it in describing the updated UI,
> where more precision is expected, anyway.
OK. I'll reword. That said, I need to at least present what the
choices are as that is what the user will see and what the functionality is.
>
>>>
>>> The solution in use case 3 tries to infer format based on the
>>> attributes specified, and misses existing and future options. For
>>> example, it's possible to install SVR4 packages from an http URL,
>>> and IPS will have an on-disk format in the future. I strongly
>>> recommend making declaration of package type explicit, if that's
>>> necessary, or have it automatically resolved by your solution based
>>> on a recognition of the location's format (which may be relatively
>>> simple).
>> Good point. Better not to assume a certain format or location type
>> for different kinds of packages. I think being explicit about the
>> type of package is better than resolving it automatically for the
>> following reasons:
>> - It makes the package type explicit in the manifest, with no extra
>> effort on the user's part. (Instead of "package" elements, we can
>> have "IPS", "legacy" and "DU" elements to call out the specific types.)
>> - It is more maintainable, since if some new format of a package is
>> introduced, the installers won't have to be updated to recognize them.
>>
>> Additionally, it is simpler for us to implement at the outset.
>
> I would not use "package" elements. Perhaps call it a "driver_bundle"
> or something of the sort with an additional "type" attribute. This
> avoids further overloading the package term, and limits the amount of
> change to the schema required for additional types, should any future
> ones be needed.
I changed "package" elements to "IPS", "legacy" and "DU" elements.
>
>>
>> See sample below.
>>> You mention a compatibility requirement for DU packages, but I'm
>>> unclear how you expect to make that determination.
>> Packages in a DU image are nestled under a subdirectory with the
>> version in its name. On NV it is sol_211, for 5.11. That version is
>> checked when a DU image is installed. This version is how I would
>> check compatibility. (Reference: in onnv, check
>> usr/src/cmd/itutools/updatemedia.ksh and pkg2du.ksh)
>
> For our purposes here, that's potentially excessively restrictive;
> many S10 drivers will run just fine on Solaris next. At most I'd
> expect a warning from such a check.
OK. But there's also the case of a single DU image containing multiple
OS versions of the same driver. If we're going to accept OS versions
other than our own, we can start with our own and work our way down
until we find one with the driver we want, to get the latest version the
image has of that driver.
"Working our way down" is a maintainable solution as long as there is an
ordered pattern to the versions from here forward. (For example, if the
current version is "a" and the next version is "b", we can start with
the current letter and "decrement" in the future without having to
change the code.)
Does this sound reasonable?
Thanks,
Jack
> Dave
