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? > > 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. 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) > > [ More a nit for future design, but the "special_driver" tag here > isn't descriptive enough; "add_drivers" or something would be an > improvement ] OK. See example below. > > One thing I would suggest making allowances for in the design is to > allow the AI cases to specify the driver be used only during > installation, but not installed to the system. This may be useful > (and perhaps necessary) for some image-production scenarios, where a > system with proprietary devices is used to assemble a golden image for > general redistribution. It's a corner case, but probably easily > handled with some additional attributes on the package specification. > Sure. We can add an attribute for each package to that effect. How about "noinstall" to signify we're not going to install that package, but only use it in the installation environment. So, with all of this, the old example: <special_drivers> <package name="SUNWraiddev", repo="http://myrepo";> <package name="SUNWtata,SUNWtata2", pkgdir="/media/usbstick/tatadir"> <package name="*", DUimg="/media/du_volume"> </special_drivers> morphs to this (with "noinstall" set for the first package): <add_drivers> <IPS name="SUNWraiddev", location="http://myrepo";, noinstall/> <legacy name="SUNWtata,SUNWtata2", location="/media/usbstick/tatadir"/> <DU name="*", location="/media/du_volume"/> </add_drivers> I'll work on a better name than "add_drivers" but it will sit for now... > I'm doubtful of ruling non-Sun SPARC "not worth supporting". I think > it would be more useful to say that it's expected to work, but will > not be tested by the project team. OK. Thanks again for your comments, Dave. I've updated the use-cases-summary with this info and reposted. Jack > > Dave
