Terry (Sarito) Whatley writes: > No, the existing power management subsystem is not intended to consume > this information. > The existing pm framework will eventually be superseded* by a > resource manager-based architecture where power management control > of different devices will be taken by "resource managers" which have > specific knowledge of the pm properties and usage of the devices.
OK; that sounds like a better answer. So where is the documentation for that future project? Is this case dependent on some other case that provides the higher-level architectural details? > The only intersection between this specific case and the existing pm > framework is the pm_trans_check(9F) function, which remains backwards > compatible with the existing code while extending identical functionality > to a class of devices (non-SCSI disks) not currently served, since this case > would make the relevant information available. OK. > The directly dependent case on this one is likely to be approximately > "kernel interfaces for resource power managers" which might also be > used by a "power aware dispatcher as a cpu resource manager" case, and > likely a "file system as a pm resource manager" case, etc. That sounds a bit backwards to me, at least for the ARC. I understand that, as a consumer of these interfaces, the project you're describing is "dependent" on this one to export the interfaces, but from an architectural point of view, it's that *other* case that will be defining the things that this project needs to export and specifying how they'll be used. The dependency for us (in understanding the intended system architecture and then applying that understanding to the subsystem under review) runs the other direction. I don't think we can review this project without that information. Can it be made available? (In the meantime, it sounds like this case needs to be marked "waiting need spec.") > We intended to present all levels together, but have been asked to produce > these low level interfaces in the mean time for intermediate use while > we finish the design documentation necessary to present the "next level > up" case. We are confident that the interfaces exposed here will not > be changed by the next level case, as they are specific to the description > of the power states supported by modern disk drives, which will be needed > whatever the upper level interfaces are. You're asking us to approve the cart before the horse. On what basis should we review this? "Yes, those do indeed look like a bunch of interesting parameters, and maybe somebody could use them someday" doesn't seem like the right answer. > This case does not require changes in the autopm framework except > minor changes in pm_trans_check(9F), which is just an enhancement > to improve current functionality if additional information > (cycle count info from non-scsi devices) is available, and the addition > of a hook for later use (the "dip" argument). Except, of course, that most of the interfaces described here aren't needed at all by the existing autopm framework. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
