[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 09/17] xen/hypfs: move per-node function pointers into a dedicated struct
On 03.12.20 10:12, Jan Beulich wrote: On 03.12.2020 09:47, Jürgen Groß wrote:On 02.12.20 16:36, Jan Beulich wrote:On 01.12.2020 09:21, Juergen Gross wrote:static int hypfs_write(struct hypfs_entry *entry, XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)As a tangent, is there a reason these write functions don't take handles of "const void"? (I realize this likely is nothing that wants addressing right here.)Uh, this is harder than I thought. guest_handle_cast() doesn't handle const guest handle types currently: hypfs.c:447:58: error: unknown type name ‘const_void’; did you mean ‘const’? ret = hypfs_write(entry, guest_handle_cast(arg3, const_void), arg4); ^ /home/gross/xen/unstable/xen/include/xen/guest_access.h:26:5: note: in definition of macro ‘guest_handle_cast’ type *_x = (hnd).p; \ ^~~~ Currently my ideas would be to either: - add a new macro for constifying a guest handle (type -> const_type) - add a new macro for casting a guest handle to a const_type - add typedefs for the const_* types (typedef const x const_x) - open code the cast Or am I missing an existing variant?I don't think you are. Both of your first two suggestions look good to me - ultimately we may want to have both anyway, eventually. For its (presumed) type safety I may have a slight preference for option 1, albeit afaics guest_handle_cast() doesn't allow conversion between arbitrary types either (only to/from void). It's quite unfortunate that this requires an explicit cast in the first place, but what do you do. Right. I'm going with variant 2, as variant 1 is not really easy to achieve without specifying the basic type as a macro parameter - which will basically be variant 2. Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |