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. > It gets a little tough to handle the case of in memory CMOS. I don't quite get your point here. The content of the drive is copied in the RTC init routine into a private char array. How could the type of the drive may be a problem here? Regards, Mathias