qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] s390: Virtual channel subsystem support.


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH 2/5] s390: Virtual channel subsystem support.
Date: Thu, 9 Aug 2012 09:19:58 +0200

On Wed, 8 Aug 2012 19:39:33 +0000
Blue Swirl <address@hidden> wrote:

> On Wed, Aug 8, 2012 at 7:34 PM, Peter Maydell <address@hidden> wrote:
> > On 8 August 2012 20:16, Blue Swirl <address@hidden> wrote:
> >> On Wed, Aug 8, 2012 at 8:17 AM, Cornelia Huck <address@hidden> wrote:
> >>> On Tue, 7 Aug 2012 21:00:59 +0000
> >>> Blue Swirl <address@hidden> wrote:
> >>>> Please use more descriptive names instead of acronyms, for example 
> >>>> SubChStatus.
> >>>
> >>> I'd rather leave these at the well-known scsw, pmcw, etc. names. These
> >>> have been around for decades, and somebody familiar with channel I/O
> >>> will instantly know what a struct scsw is, but will need to look hard
> >>> at the code to figure out the meaning of SubChStatus.
> >>
> >> If they are well-known and have been around for so long time, are
> >> there any suitable header files (with compatible licenses) where they
> >> are defined which could be reused?

There's the Linux headers, but they are not exported as this is not a
user space interface (on the guest side).

Otherwise, most code dealing with channel I/O is probably not written
in C ;)

> >>
> >> Otherwise, please follow CODING_STYLE.
> >
> > I think we should follow CODING_STYLE for capitalisation issues
> > but generally if the device's documentation has standard abbreviations
> > for register names, structures, etc, etc we should use them. Often
> > this code has to be maintained later by somebody else who might not
> > be familiar with the general operation of the hardware and who is trying
> > to match up the code with whatever the data sheet says. Following the
> > naming used in the h/w docs makes that job easier.
> 
> Yes. typedef struct SCSW {} SCSW; should be OK too.

Then I'll use something like that.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]