Hi Peter.
Thanks for your review. Comments inline...
On 08/13/09 13:20, Peter Tribble wrote:
> On Thu, Aug 13, 2009 at 3:45 AM, Jack Schwartz<Jack.A.Schwartz at sun.com>
> wrote:
>
>> Hi everyone.
>>
>> I haven't received any email comments on the spec.
>> Is the spec so good that no one had anything to say? :)
>>
>
> 1.2 You allow for delivery of drivers using 3 mechanisms - IPS, SVR4,
> and a DU image. However, you only mention searching the Device Driver
> Utility database for IPS packaes. Does the database only contain IPS
> packages? In that case, how does the user find drivers that are only
> available in SVR4 form?
>
All packages the DDU database points to are IPS packages. These are
categorized as "Solaris" packages. Other entries it categorizes are
OpenSolaris (which point to OpenSolaris project websites) and ThirdParty
(which point to other websites).
Even if the DDU pointed to non-IPS packages, though, I would propose
that Driver Update not use them. I would only want an automatic
installation of a driver if that driver has gone through the process
needed to make it into an official OpenSolaris distribution ("certified"
is as close a term as I can think of here). We can't be responsible for
the results if the DDU were to install a third party driver from a
source we know nothing about.
All of the above applies only to automatic search and install of
drivers, which is what the database is used for. If you know of a third
party driver you want to use, or have an SVR4 driver left over from S10
you want to install on your older hardware, you can do this. In fact,
support of DU images is just for this purpose: to make it easy to
install older drivers without having to convert their format.
> 3.3 Why add specific support to AI? I would have thought that adding
> additional drivers to the installed image was no different to adding any
> other package.
You are correct in that the mechanics of adding an additional driver to
the installed image is the same as adding any other package to that
image. (In fact, updates to the DDU for doing manual installs of
packages will be shim layers which call pkg or pkgadd to do the real work.)
So why is this needed? Special drivers have to be added to the
installed image so they are available to aid in the installation
itself. One needs to add the special driver for a legacy raid card
before the disks of that card can be used as a target for the install.
That driver won't be available soon enough if its package is merely
listed as one of the packages to install.
> And traditionally I would have rebuilt the miniroot - why
> not do that (needed for getting the network driver on in any case).
>
You still can, but Driver Update is a heck of a lot more convenient for
most cases.
Network drivers may need special attention. In the case of net-booted
AI, you've already got a network connection when you start. But in the
case of media-booted AI, you may not have a network connection. Driver
update can certainly load a driver from local media (e.g. USB stick) but
configuring the AI client's network stack to use it is another issue.
(You'd still have the problem even without Driver Update, though.)
As I see it, net configuration would fall under the domain of the AI
Client effort.
> (I think I interpret the spec here as saying that you specify an updated
> driver location and it gets automatically loaded into both the installation
> environment and the installed system.)
>
Correct. The driver will not only be used during the installation, but
it will also be installed in the target environment.
I need to clarify in the spec though that specifying the "noinstall"
flag is the way to use a driver during an installation but not install
it. It is there in the first example in the first <bundle>. However, I
forgot to explain it in the spec.
> For AI, why is searching there? I wouldn't expect that I would be able
> to contact the search system, and I wouldn't want the system to start
> guessing what drivers I do or don't want - I would want to explicitly
> control what gets installed.
>
In OpenSolaris, there could be drivers which haven't been included in
the AI image (and thus not in the client-booted installation
environment) but yet are in the repo. This is how the search can be useful.
The "database" used by the DDU and which will be used by AI through a
DDU library, is a flat file delivered with the DDU. It is nothing fancy
and doesn't require going to a special database system.
We can specify a repo for the automatic search and install. This is to
accommodate testing teams, which may want to test with a special repo.
For this reason, I suggest in the spec that the database that is used
come from the repo it represents,. Suppose for example, that the /dev
repo has a more current set of drivers than /release. We'll need the
/dev repo's database to know about the new driver set.
We don't want the system to automatically search and install drivers
without the user's permission. The user needs to explicitly put the
<searchall> tag into the manifest to enable this feature. You can
always install manually if you prefer, to have explicit control.
One detail which wasn't discussed in the spec but needs to be, is how
the manual and automatic options can interact. I'm going to propose
that <searchall> can be done as the last "specification" in an
<add_drivers> group. This way, specific drivers can be added
explicitly, and then <searchall> can be used to find the rest. Human
interaction can drive this same behavior with the live CD and text
installers too, as already proposed.
> The statement:
>
> > Third party drivers will not be installed automatically.
>
> confuses me. Isn't that one of the things you're trying to automate?
>
Again, to clarify, you *can* add third party drivers to an installation
environment to aid an installation but you have to add its package name
and location to the manifest.
By "installed automatically" I meant "search the database for a driver
to match a device and install its package". This couldn't happen for
third party drivers. How would the database know about them? Even if
the database could, how could the reliability and security of those
drivers be certified since the location could be arbitrary? In the case
of AI, third party drivers can't be installed anyway, in many cases,
because to download them would require human interaction (e.g. clicking
at the third party website to agree to their license, click the download
button, etc); AI is hands-off.
Thanks so much for your feedback. You are helping make my spec more
complete and clear. I'll be updating the spec and reposting it within
the next couple of hours.
Thanks,
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090813/4996e3ca/attachment.html>
