From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8B59C47434 for ; Fri, 4 Dec 2020 09:16:35 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 491BA227C3 for ; Fri, 4 Dec 2020 09:16:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 491BA227C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.44264.79347 (Exim 4.92) (envelope-from ) id 1kl7CQ-0001t7-HP; Fri, 04 Dec 2020 09:16:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 44264.79347; Fri, 04 Dec 2020 09:16:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kl7CQ-0001t0-ER; Fri, 04 Dec 2020 09:16:22 +0000 Received: by outflank-mailman (input) for mailman id 44264; Fri, 04 Dec 2020 09:16:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kl7CP-0001sv-NM for xen-devel@lists.xenproject.org; Fri, 04 Dec 2020 09:16:21 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56139137-c5f5-40c0-aabc-8e4516927846; Fri, 04 Dec 2020 09:16:20 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id EB797ACC6; Fri, 4 Dec 2020 09:16:19 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56139137-c5f5-40c0-aabc-8e4516927846 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1607073380; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=elv0qx14rjDZkrgz9XMZ0WUbGL2H6cwfwNztroy1OWk=; b=lh6AdLF5IIhWZ8MmfCOl5EvcYZ2mHl8eBBqWMUKorZJ9eeV47tbJSyHitq070y5jSUz/5h ioXwqZSjJ3zZGNlzksHOuCx0mkP91voJCieXlGlsKcuSJi/W7o0fNysb8zUqlCjxVFCP8W 9eReQs+TIRWhBvpsAKEa4bmE563yGUg= Subject: Re: [PATCH v2 14/17] xen/hypfs: add support for id-based dynamic directories To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20201201082128.15239-1-jgross@suse.com> <20201201082128.15239-15-jgross@suse.com> <369bcb0b-5554-8976-d3fe-5066b3d7cdce@suse.com> <774ca9f3-3bbe-817f-5ecb-76054aa619f5@suse.com> From: Jan Beulich Message-ID: Date: Fri, 4 Dec 2020 10:16:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <774ca9f3-3bbe-817f-5ecb-76054aa619f5@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 04.12.2020 09:52, Jürgen Groß wrote: > On 03.12.20 16:44, Jan Beulich wrote: >> On 01.12.2020 09:21, Juergen Gross wrote: >>> --- a/xen/common/hypfs.c >>> +++ b/xen/common/hypfs.c >>> @@ -355,6 +355,81 @@ unsigned int hypfs_getsize(const struct hypfs_entry *entry) >>> return entry->size; >>> } >>> >>> +int hypfs_read_dyndir_id_entry(const struct hypfs_entry_dir *template, >>> + unsigned int id, bool is_last, >>> + XEN_GUEST_HANDLE_PARAM(void) *uaddr) >>> +{ >>> + struct xen_hypfs_dirlistentry direntry; >>> + char name[HYPFS_DYNDIR_ID_NAMELEN]; >>> + unsigned int e_namelen, e_len; >>> + >>> + e_namelen = snprintf(name, sizeof(name), template->e.name, id); >>> + e_len = DIRENTRY_SIZE(e_namelen); >>> + direntry.e.pad = 0; >>> + direntry.e.type = template->e.type; >>> + direntry.e.encoding = template->e.encoding; >>> + direntry.e.content_len = template->e.funcs->getsize(&template->e); >>> + direntry.e.max_write_len = template->e.max_size; >>> + direntry.off_next = is_last ? 0 : e_len; >>> + if ( copy_to_guest(*uaddr, &direntry, 1) ) >>> + return -EFAULT; >>> + if ( copy_to_guest_offset(*uaddr, DIRENTRY_NAME_OFF, name, >>> + e_namelen + 1) ) >>> + return -EFAULT; >>> + >>> + guest_handle_add_offset(*uaddr, e_len); >>> + >>> + return 0; >>> +} >>> + >>> +static struct hypfs_entry *hypfs_dyndir_findentry( >>> + const struct hypfs_entry_dir *dir, const char *name, unsigned int name_len) >>> +{ >>> + const struct hypfs_dyndir_id *data; >>> + >>> + data = hypfs_get_dyndata(); >>> + >>> + /* Use template with original findentry function. */ >>> + return data->template->e.funcs->findentry(data->template, name, name_len); >>> +} >>> + >>> +static int hypfs_read_dyndir(const struct hypfs_entry *entry, >>> + XEN_GUEST_HANDLE_PARAM(void) uaddr) >>> +{ >>> + const struct hypfs_dyndir_id *data; >>> + >>> + data = hypfs_get_dyndata(); >>> + >>> + /* Use template with original read function. */ >>> + return data->template->e.funcs->read(&data->template->e, uaddr); >>> +} >>> + >>> +struct hypfs_entry *hypfs_gen_dyndir_entry_id( >>> + const struct hypfs_entry_dir *template, unsigned int id) >>> +{ >>> + struct hypfs_dyndir_id *data; >>> + >>> + data = hypfs_get_dyndata(); >>> + >>> + data->template = template; >>> + data->id = id; >>> + snprintf(data->name, sizeof(data->name), template->e.name, id); >>> + data->dir = *template; >>> + data->dir.e.name = data->name; >> >> I'm somewhat puzzled, if not confused, by the apparent redundancy >> of this name generation with that in hypfs_read_dyndir_id_entry(). >> Wasn't the idea to be able to use generic functions on these >> generated entries? > > I can add a macro replacing the double snprintf(). That wasn't my point. I'm concerned of there being two name generation sites in the first place. Is this perhaps simply some form of optimization, avoiding hypfs_read_dyndir_id_entry() to call hypfs_gen_dyndir_entry_id() (but risking the two going out of sync)? Jan