OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [virtio-comment] [RFC PATCH v2] virtio-rtc: Add device specification.

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Peter Hilber
> Sent: Wednesday, October 18, 2023 10:30 PM

> > I will need to re-read the rtc v2, but the generic approach I had in mind is to
> take the ctrl vq opcode being common between net and rtc.
> > And follow the net's cvq command response format (donât recall if fullfils rtc
> or not).
> > And thatâs it. Rtc and net gets both same command, same response.
> > Net will have feature bit to indicate this functionality exists, for rtc it is implicit
> as its being and rtc device.
> >
> But that would force virtio-rtc to use the not padded request/reply headers
> which the virtio-net controlq has, implying dedicated descriptors for
> class/command and ack to still have natural alignment in command-specific-
> data and command-specific-result.
> 	struct virtio_net_ctrl {
> 		u8 class;
> 		u8 command;
> 		u8 command-specific-data[];
> 		u8 ack;
> 		u8 command-specific-result[];
> 	};
> To me, this looks like a net legacy issue, so it should be addressed in net by
> encapsulating the aligned RTC request/response.
Right. It makes sense to have rtc request as command-specific-data and rtc response as command-specific-result. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]