[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/5] common/vmap: Fall back to simple allocator when !HAS_VMAP
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Fri, 29 Nov 2024 11:24:00 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UEaVoGNlz0JdoRaalEiKBwAzNlsZ2/DAclO3zeuwz/Q=; b=HV+yfeusjPkOABHivg5eAxCpx7vBXAJvRh72hYI9xJ7XWGfAy4ARbZyWdBRw4phdR4SogL0GjzP9bAezgBG1oG1P5AHHrUzsfouApfW5udeOeS8bAV2bQ5Jjdd/F+UxmVm41LY6F/HoHPJK1jUG2Fh88CBxlV7WezTY1bySzV9H2u8rpK4YQVTj+yX06NOIr3uuaCrNJBocprlAvSUuhNoWdGAdmNlUSKooXNi4jj/h+fcCgS7KYEZJK/WhNkFi6ycjDx67K4y4/HKIqI5zxVu0Ylvoe5Felns03tdn4OLQt7CJqNaYyt9lt/nLInIZCq1ETEYw1FY1QWodEsdxe7A==
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UEaVoGNlz0JdoRaalEiKBwAzNlsZ2/DAclO3zeuwz/Q=; b=Nht0of/M1gmwgbj07zf9k25mYGx6YlNC6hyBUsQj9HEJbKuTg63yK2mgWo5veuwl8Ym4/p2RMwYk+bUQRanuu9bcluEDJJ+TD6Wz2bgON/80KdGHrA+WsT5qT1o9FGz1aR7Ty7pCfGbRjMIFRpKzbAY5NvR45VMXz/nTJzHYYiYdzKQe0ga5Mrbg+sqF0ByqZMnCEkH+vx3xOH224+v3j6ZGzig993INdG+Youv1nUUjWdkE8WMNDLxTFx5TiLuVWF8L74ofv+7rMBgIgykLLAq2MYlmTosjHQTYz4grw1therGym4WUEmghXS0JPPBrqmfVjL5TVE5dyRwm5gJmSA==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=rEIQcGrgdPsigwCzfaoumglQE4bsuOw+8dGNGzrRTT6YbSZFlMFJKAzn6qFh/3bOqhkisAgOsu2NCQZog8zbWN+yIDJQ806KfWIflQSa0vUVnnpX5R0weZvLe4eYSlTZfeCUlPrkPbPmHYwR0ERGnaj9Ko3UGKRoKFgIonLF6zKoMhQSraT7d8krfOTT7eZRLV8Xkow3ahoVwBysn9jJiU6WLljH9yYzHkwT/WdtwPZGY36F6W8jz6AEOTH66VUHbKmdMGEzfxLRnqkN6MxiZPkUYIltdDYHjR/Hd/g3RB1OfzNwvucu2SffxOzgj9M4g7Lc0LL+gO6K9HU3lZOrtQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SRbqkRuhDuE+Tto3XkSbjkiaKMsQDcpFox12sLHXsce4XpGkNw9gjsAto4HDNkPL/QWOO45j1OgI4kAfz4TND3L3AhrnaPH+QwQ+b2CuPt28WL/vSNAPGJsvg/ihLSgZRnNLrX1HjzRAgU6CsL4wJRtjEElMCPour88a6rsRIBEVCKsiSqCcRTCtjajdreFTPulNnpSeiOVdkJOqw4Xo/KsisdO55CTRfFFrqXfDFQfyFqFfblZTZWme4b4/ScRBngMys7KWGN4RvD8pMrgw9UVs1ABWIglnQRps2uyD1srNvRzOclrhgEqeXg2bKDm30R+Vd+KkpykFMI97O40xcA==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 29 Nov 2024 11:24:23 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Thread-index: AQHbQj8EJeBBpea3PECsMrqs79+q+7LOGRaAgAAB8gCAAAJmgIAAAE8A
- Thread-topic: [PATCH v3 1/5] common/vmap: Fall back to simple allocator when !HAS_VMAP
>>>
>>> Just to double check: Was it at least considered to use simple #define-s
>>> to effect the aliasing? Wrapper functions like the above ones have the
>>> downside of needing touching (easy to miss) when the wrapped function
>>> types change in whichever minor way. (And yes, I do understand that we
>>> generally aim at using inline functions in preference to macros.)
>>
>> Yes, I think I tried and I didn’t have issues using #define-s, I asked here
>> https://patchwork.kernel.org/project/xen-devel/patch/20241115105036.218418-2-luca.fancellu@xxxxxxx/#26123448
>> about a preferred approach, but I didn’t have any reply, so I went for what
>> I believed was preferred as you said, static inline-s instead of macros.
>
> As Andrew's idea didn't work out, personally I think the simple #define
> approach you suggested would be preferable in this case. There is in
> particular no type-safety concern here, as the wrapped functions will
> all have the intended type checking applied.
ok, I’ll re-spin this one with #defines.
>
> Jan
|
