Hi Dave. On 08/18/09 06:49, Dave Miner wrote: > Jack Schwartz wrote: >> Hi Dave. >> >> Thank you for your comments. Responses inline. >> >> On 08/13/09 15:30, Dave Miner wrote: >>> Jack Schwartz 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? :) >>>> >>>> Seriously, if you do have something to say, please let me know >>>> ASAP. The spec is starting to be used. >>>> >>>> Note that the link has changed (email was sent about this). It is: >>>> http://www.opensolaris.org/os/project/caiman/Driver_Update/du-func-spec.txt >>>> >>>> >>>> >>> >>> In section 3.3, Stephen had suggested use of p5i format to specify >>> IPS packages. Is there a reason this wasn't chosen? >>> >> I don't understand the question given the context. The context is >> that the manifest needs to differentiate IPS vs SVR4 vs DUimage type >> packages. I interpreted Stephen's email to mean "Don't use the term >> IPS to specify IPS packages, and so I changed all references to >> "pkg(5)" or "pkg". AI will read the "add_drivers" entries in the >> manifest to know which packages are needed to install, in much the >> same way that AI reads the manifest to get the list of packages to >> install or that DC reads the package list it needs to build an image. >> >> If there is more that I'm not getting here, please clarify. > > Stephen's message was perhaps a little subtle, but I believe there was > a suggesting lurking there to use a p5i link specification (or p5c, > which will be the on-disk format, once it's built), rather than > separate type, name, location as you have specified. This is > something we'll need to be supporting in the AI and DC as well. OK. So right now (for context) we have this:
<bundle type="pkg", name="SUNWraiddev", location="http://myrepo"/> We could add something like this: <bundle type="p5i", name="SUNWraiddev.p5i"/> where the p5i file would contain the package and repo. I'll update the spec with this; if you had something else in mind please let me know. As for p5c files, they are not yet documented and are not completed yet AFAIK. I'd like to defer p5c work as an RFE for later. >>> 5.2.1: Why not provide a selectable option in AI to have more >>> aggressive, "anything goes", automatic installation? I'm >>> unconvinced of the "likely to be interactive" assertion here. >> My first response to this was "sure, why not". But then when I >> thought about it, it opens many cans of worms. >> >> Right now, the scope is doable. The kind of pkg we say we'll process >> is represented in the database by just its name. We know what that >> name represents and how to process it. >> >> If we open up to http URLs we don't know how to navigate them, as >> they are all different; there can be anything in a webpage. Since >> there is the possibility that webpage will be interactive, we have to >> assume that it will be as the worst case scenario; how do we process >> an interactive webpage from a non-interactive tool? Or, maybe you >> know how to tell whether a URL is interactive or not? If so, please >> let me know. >> >> If we open up to ftp, that could be a file or a directory; if a >> file, we don't know what kind of package that file represents. Could >> we figure it out? Maybe, but the scope broadens greatly and we >> already have a lot to do. >> >> There may be other formats we could accommodate as well (the DDU >> database doesn't have other kinds right now) but again the scope is >> not feasible IMO. > I think you're making this too hard. Why would we not just require > that the link be directly to an installable software bundle in one of > the formats supported? We discussed this today and decided that it was sufficient extra work without sufficient benefit, to defer it until later. I'll file an RFE. >>> >>> 5.2.5: It seems that the download of the DDU package isn't part of >>> installing, but part of searching? >> Yes. The database needs to be keyed to the repo being searched. >> >> I changed the wording to say that the database download is part of a >> package install when the database is used. >> >> I would like to see the database split out from the rest of the DDU >> package, to avoid issues with package dependencies, etc, when the >> database gets downloaded. I mention this in section 1.4, the >> interdependencies section. >>> >>> 5.4.1.1: Were actual performance comparisons done to determine if >>> boot time is affected? Just hoping this is based on data. I also >>> have a concern about memory impact, which isn't mentioned here. (OK, >>> I guess it is in 5.4.2.2...) >> Dell D630 laptop, Intel dual core T7700 2.40Ghz, 2Gb memory >> >> Dual cores enabled: no discernable time difference: >> boot: ~32 sec from select-desktop-language menu to >> stopwatch->arrow transition in Gnome >> login: ~16 sec from login password entry to stopwatch->arrow >> transition in Gnome >> >> One core BIOS config (prtconf shows only one CPU): >> boot: from select-desktop-language menu to stopwatch->arrow >> transition in Gnome: >> 34.75 with DDU >> 33.90 without DDU >> login: from login password entry to stopwatch->arrow transition in >> Gnome: >> 16.25 with DDU >> 16.10 without DDU >> >> Thanks for mentioning memory size. This led me to check it. I >> forgot that the live CD GUI doesn't run well (if at all) in 512 Mb. >> >> I tried running with DDU kicked off automatically, in VB with >> 512Mb... No go. But the DDU doesn't work if I kick it off manually >> after boot is completed either... If we want this to work in 512 Mb >> is a problem of larger scope than just Driver Update. >> >> DDU does run in 768 Mb however (when kicked off from boot as well as >> manually). For now, I've changed the "512Mb" in the spec to "768Mb". > > I agree that it's a larger problem, but I would expect that DDU should > run within 512 MB since that is the product requirement at present. > Whether we can accommodate adding drivers at runtime within that > memory budget is a separate matter, I suppose, but there's a product > requirements discussion that has to be had. Just changing the spec > here doesn't mean it's acceptable. OK. I've changed the spec back to 512. Actually, the test I ran isn't really legit, since it was in the GUI environment and the spec calls out 512Mb for text mode. This can't be tested yet as it doesn't exist. My hope is that since Gnome won't be up, that there will be less memory used and the text-mode DDU will have enough memory to run. Also, the DDU itself is text base so it will probably use less memory than the GUI version. Thanks, Jack > Dave
