Hi Peter.
On 08/16/09 15:35, Peter Tribble wrote:
> On Thu, Aug 13, 2009 at 11:17 PM, Jack Schwartz<Jack.A.Schwartz at sun.com>
> wrote:
>
>> Hi Peter.
>>
>> Thanks for your review. Comments inline...
>>
>
> I must be being dense. I understand even less how this might work than
> I did before...
>
>
>>> 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.)
>>
>
> Thinking about this more: why would I have to explicitly specify that a driver
> identified as being required by a piece of hardware in my system be
> installed? Why wouldn't the installer just install all necessary drivers
> (unless
> explicitly told to ignore them, of course)?
>
I agree it would be nice to install all drivers which a system needs
automatically. (This is <searchall> in the AI manifest.) If we do this
we need to make sure it plays well with use cases where the user
explicitly specifies certain drivers to install.
I will change the functional specification to include that the AI
manifest template have searchall listed. This way, if the user does
nothing, drivers will be automatically searched. The user is also free
to take the searchall out, or to add requests for explicit drivers in
addition.
>
>> 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.
>>
>
> But, if I'm running AI, then I'm booting an AI image. I would expect that
> to have all the "official" drivers in it already by default. All the
> drivers that
> DU knows about and you're proposing to allow automatic installation of
> will already be present - or should be.
>
In most cases, all needed drivers will be present. However, the AI
image is also pared down to cut load time. The AI image may be missing
a driver for a not-often-found device which exists in the repo.
> (That's different from installing off the live cd, where space limitations
> may force you to skip a whole load of drivers.)
>
>
>>> 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.
>>
>
> What I meant was - wouldn't Driver Update just do that for me transparently?
>
Driver Update wouldn't need to rebuild the bootroot as it's already
unpacked and running in RAM by the time Driver Update would run. Driver
Update would just install the new driver into the RAM-based OS image.
(Note: the installer would keep track of such drivers and their
packages, so that they can be installed into the target as well.)
>> Network drivers may need special attention. In the case of net-booted AI,
>> you've already got a network connection when you start.
>>
>
> Only if the driver is in the miniroot. So you rebuild the miniroot.
> Given that you
> have to do that for some drivers, why not do it for all?
>
OK. Maybe you are asking why Driver Update doesn't just build a whole
new AI image with the added drivers. This would get around the problem
of setting up a network stack after some special driver needed to be
installed as the system would just boot the new image with the new
driver and the network through the newly-working device would just work.
The point of Driver Update though is to not have to rebuild the AI image
in order to use rare devices during install. There are situations where
Driver Update shows its limitations, like the networking case.
Even though this networking case is out of scope for now, I am wondering
if we can revisit this in the future. What is the feasibility to tag an
added driver as a network driver and automatically reconfigure the
network stack as part of the install of the driver? Then no image
rebuild would be required and the network would just work. Not sure how
useful this would be, how many systems would benefit from this? If
there are many, it would be worth considering. I'll file this as an RFE.
>> But in the case of
>> media-booted AI, you may not have a network connection.
>>
>
> Realistically, that's not AI. If it's requiring the level of
> intervention required
> to work around the lack of a network driver, then it's not going to be hands
> off.
>
>>> 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.
>>
>
> Again, my question would be: why are they missing? And if they are missing,
> then the approach would be to add them to the image rather than getting DU
> to search for them.
>
>
>> 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.
>>
>
> So it's delivered with the "media" (including the AI image)? In that
> case, how does
> it get updated?
>
The database used should be of the selected repo, and the functional
spec now states that. To aid this, the functional spec also states that
the database be decoupled from the rest of the DDU, to remove the
database of package dependency issues.
>> 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.
>>
>
> So you install from /dev, and you just get the updated drivers without doing
> anything.
>
That's the idea.
>
>> 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.
>
> Quite. So I would download the driver package, and run whatever magic was
> necessary to add the package to my AI server, and that would be all I had to
> do. All done on the server - the client does nothing.
>
The model is that the client downloads or otherwise obtains the packages
it needs. That said, if you wanted to have a stash of packages on the
server, that's OK. You could set up the server to dish them out to the
client when the client requests them as the client installs. You could
set up an SVR4 package at an http URL on the server, for example, and
then have the AI manifest point to it.
Thanks,
Jack
>> 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,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090818/99bf259b/attachment.html>
