On Tue, 30 Oct 2012 15:05:23 +0100 Alexander Graf <[email protected]> wrote:
> > > On 30.10.2012, at 15:00, Cornelia Huck <[email protected]> wrote: > > > On Tue, 30 Oct 2012 14:41:46 +0100 > > Alexander Graf <[email protected]> wrote: > > > >> On 10/30/2012 02:03 PM, Cornelia Huck wrote: > >>> On Mon, 29 Oct 2012 19:37:10 +0100 > >>> Alexander Graf<[email protected]> wrote: > >>> > >>>> On 29.10.2012, at 19:34, Cornelia Huck wrote: > >>>> > >>>>> On Mon, 29 Oct 2012 19:12:54 +0100 > >>>>> Alexander Graf<[email protected]> wrote: > >>>>> > >>>>>> On 29.10.2012, at 14:07, Cornelia Huck wrote: > >>>>>>> +static void virtio_ccw_kvm_notify(struct virtqueue *vq) > >>>>>>> +{ > >>>>>>> + struct virtio_ccw_vq_info *info = vq->priv; > >>>>>>> + struct virtio_ccw_device *vcdev; > >>>>>>> + struct subchannel_id schid; > >>>>>>> + __u32 reg2; > >>>>>>> + > >>>>>>> + vcdev = to_vc_device(info->vq->vdev); > >>>>>>> + ccw_device_get_schid(vcdev->cdev,&schid); > >>>>>>> + reg2 = *(__u32 *)&schid; > >>>>>> That cast looks quite ugly. Can't you just access the field in there > >>>>>> you need? Or if it's multiple fields do a union over them? Or assemble > >>>>>> them by hand in C? > >>>>> I think the cast looks less ugly than using a union to morph it around. > >>>>> I want the schid with all fields filled out anyway, since this is what > >>>>> identifies the subchannel. > >>>> How about a helper function that returns a u32 for a struct > >>>> subchannel_id in arch/s390/include/asm/schid.h then? > >>> This would just move the cast around, no? I don't think that would > >>> improve readability. > >> > >> It would take it from the user of that struct close to the definition of > >> the struct. The fact that it's an ugly cast by then is an implementation > >> detail. This way it's a public API. > > > > But API-wise, returning a struct subchannel_id is cleaner - we don't > > want "u32 associated with that device", but "subchannel identifier for > > that device". The fact that we want to stuff it into an integer for the > > hypercall is the implementaton detail. > > The subchannel id is not an implementation detail ;) And that's why I think it should stay the way it is :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
