Mathias Krause <mathias.kra...@secunet.com> writes: > On 17.09.2010 15:27, Anthony Liguori wrote: >> On 09/17/2010 01:50 AM, Mathias Krause wrote: >>> Am 16.09.2010 19:20 schrieb Anthony Liguori: >>> >>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write >>>> the data. >>>> >>> I'll fix that as soon as I figured how to use this interface. >>> >>> >>>> I think it would be very nice to add write support too so that writes to >>>> CMOS were persisted across boots. >>>> >>> Indeed. Also I would like to have a command line interface like '-cmos >>> cmos.bin' instead of the ugly '-global mc146818rtc.file=cmos.bin'. But >>> I'm not aware how to create such an alias. Any pointers? >>> >> >> Unfortunately, it's a little complicated although it should get better >> in the future. The right way to do this today would be: >> >> -drive file=cmos.bin,if=none,id=nvram -global mc146818rtc.drive=nvram >> >> The use of -drive is historic. We'll have a better option in the future >> that will look something like: >> >> -blockdev file=cmos.bin,id=nvram -global mc146818rtc.drive=nvram > > Well, I guess "better" lies in the eye of the beholder, then ;) > > >> But in either case, I'd suggest adding an -nvram option that was: >> >> -nvram <filename> >> >> Which would do: >> >> drive_add(optarg, "if=none,id=nvram"); >> >> And then in the RTC code, default drive to nvram. > > I managed to add the nvram option but how do I get a reference to the > drive back in the RTC code? Would I just loop with drive_get(IF_NONE, 0, > i) until the id of the returned drive is "nvram"? Doesn't sound right > but I've found no better solution due to the lack of an > drive_get_by_id() function.
Use DEFINE_PROP_DRIVE() to define mc146818rtc's property drive, and it's automatic: qdev assigns a pointer to the BlockDriverState. To access DriveInfo, use drive_get_by_blockdev(). I doubt you need that. [...]
