(Note: Moved to Caiman-discuss) Hi Bill and everyone.
On 08/18/09 01:59, Bill Yan wrote: > Hi Jack, > > Thanks for the detailed information you provided. It's very useful and > we think our design doc will be much based on the function spec. It's mostly complete, but it is still being changed slightly. The latest version is at the same link as before: http://www.opensolaris.org/os/project/caiman/Driver_Update/du-func-spec.txt > > After discussion, is it OK to set bi-weekly meeting at the beginning? > This is just to align with our other projects. We can change it back > to weekly if you think bi-weekly meeting is not enough later on. Thanks. Sure. We'll meet next week. For this week, we'll deal with technical issues through this email. Please read answers below and start working on the internals of the DDU library. As I mention below, I'll get you I/O interfaces for the library as soon as I can. > The following is our understanding after reviewed the function spec, > please correct us if it's different from what you think: > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > 1. we think DDU team will be in charge of the "An enhanced DDU GUI", > "A new text-mode DDU" and "A DDU library" in the deliverables section. Yes. > 2. The DDU library will contain the common functionality(scan, driver > installation etc.) and it will be called by GUI DDU, Text Mode DDU and > AI. Yes. > 3. GUI DDU will be run in background during the live cd start up and > give user notification if there is missing driver, and user have the > option to start the GUI DDU to install missing driver. Yes. The DDU will run in silent mode at boot time, and will run in add-drivers mode to add drivers. User will also have the option of starting the DDU in add-drivers mode from the start menu. > 4. Text mode DDU will have a text-based UI which can be controlled by > F-keys, and look and feel of the text-based UI will follow the > prototype of text-based installer at > http://www.opensolaris.org/os/project/caiman/TextInstallerProject/Prototype/. > Note that the prototype here was done as an intern project. It is not a deliverable. We will be developing a text-mode installer using the prototype as a reference, but it will likely be different. The functional spec for the deliverable text installer is at: http://www.opensolaris.org/os/project/caiman/TextInstallerProject/text_install_spec_v3.txt Also note that use of F-keys was just a suggestion. If you have a better way of doing it, please propose it. > The following is our questions that we have so far: > -------------------------------------------------------------------- > > 1. What's your requirement for the DDU library? > > For instance, what language(c,python?) will be used for the DDU > library? how will AI call the library? And what's the detailed > input/output interface for the DDU library? I will go to work immediately on these questions and get back to you. I'll propose to my team (and cc you and the caiman-discuss alias) what I think is best and discuss it over email. If you have a language preference or anything else, please participate in the email discussion. The functional spec calls out the following changes from the current DDU which would affect the DDU library. (There may be others too...) - Addition of installing SVR4 packages given name and location - Addition of installing packages from a DUimage given package name and DUimage location - Addition of installing pkg(5) packages given name and repo - Separation of the database from the rest of the DDU package, so that a new database can be loaded without having to reinstall the whole DDU package. Any database package should be usable with any DDU package. (This works around potential package dependency issues.) - Addition of logging the packages which get installed, to a list which the installer can use later. - Addition of error status return codes and error handling. - Addition of logging errors to the screen and to logfiles. > If possible, could you provide the source of an existing similar > library called by AI for us to follow. I will follow up on this once the language is decided. > > 2. what's your requirement for the GUI DDU? > > For instance, how will the GUI DDU be called in background during the > livecd startup? And how and where to show the notification for the > missing driver? The DDU will be called via the Gnome desktop autostart. See my blog (just written today!) for an intro. blogs.sun.com/jaschwartz I am wondering if the scan during silent mode can be made more light-weight by doing only the scan for devices with missing drivers (accomplished using "prtconf -D" and looking for devices without a driver for example) rather than checking packages and the other things which are done during a standard DDU device scan today. When one or more devices are missing drivers, a popup notification appears on the screen to say that there is at least one device missing its driver. The popup notification is similar to what NWAM uses when it finds a new interface to attach to. The add-drivers mode will display a window similar to what exists today, accept it will allow installation of a specific IPS package, SVR4 package or package from a DU image, and will allow the user to specify the location (repo, directory). Please see sections 3.1 and 5.4.1 for more details on the GUI DDU. The spec proposes an "unmount" button for unmounting selected removable media. This is useful if, say, a user has two drivers to add, each on its own USB stick. After the user finishes with the first USB stick, the "unmount" button is pushed to umount it, and the user can then insert the second USB stick to get the second driver. Please feel free to ask specific questions. It is up to you to decide which language to write the DDU in. > 3. What's your requirement for the text-mode DDU? > > For instance, what language will be used for the text-mode DDU? As the > look and feel of the UI will follow the text-based installer, will you > provide some standard toolkit for us to use for the text-mode DDU? If > not, it's better to provide some sample code for us to follow. We are researching which language the text-mode installer will be written in. It will either be C or python. We will let you know what we are going to do. Regardless of how we implement the text-mode installer, it is up to you to decide which language to write the DDU in. > > 4. By our understanding, Reboot is needed for the driver to take > effect after instanllation. What's your opinion on this portion? A reboot is needed only if there is an installed driver being replaced. (This includes when a different driver is bound to a device for which another driver is normally bound.) For this reason, Driver Update only supports adding a driver for a device which does not already have one. However, the above applies only if add_drv is called without the "-n" option. Package scripts which add drivers may call add_drv with "-n". (IPS driver actions do.) This sets up the driver but does not attach it. Not sure if add_drv without -n afterward will attach the driver, or what else (besides a reboot) can be done. This is a very important issue which I will need to address ASAP. I don't have a good answer right now. > > 5. For driver installation, DDU will install the missing driver into > ramdisk, right? How to ensure the missing driver will be installed on > disk finally? For live CD and Text-mode installers, the installer does a cpio of the running system onto the target disk. Once the DDU installs a driver, cpio will find it to copy to the target disk. > > And another question is some directories are read-only in the ramdisk, > if the missing driver installation will write on those read-only dir, > how to handle it? For example, for SVR4 packgae, /var/sadm dir(which > is read-only dir) may be used for write purpose. We will have to make sure that all directories which need to be read/write are read/write. This issue is an Install Team issue. > > 6. For the device scan, DDU will assume the system device tree has > been built up before the DDU device scan starts, is it correct? Correct. > > 7. Generally what language can be used for the driver update project > for development? This is because currently c, python, shell script, > perl have been used in the development of DDU. We need to know whether > we have to rewrite some of the code with another language. Currently perl is not included in the AI image, and would require lots of space, so please don't use it. C, Python and shell should all be OK. > > Thanks a lot, > Bill Thank you, Jack
