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. >> 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? >> >> 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. Dave
