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.

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).  You mention a compatibility 
requirement for DU packages, but I'm unclear how you expect to make that 
determination.

[ More a nit for future design, but the "special_driver" tag here isn't 
descriptive enough; "add_drivers" or something would be an improvement ]

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.

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.

Dave

Reply via email to