From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 329A0B8D2A for ; Mon, 11 Mar 2024 16:28:03 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 13805BC92 for ; Mon, 11 Mar 2024 16:27:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 11 Mar 2024 16:27:32 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id CF52748908 for ; Mon, 11 Mar 2024 16:27:31 +0100 (CET) Date: Mon, 11 Mar 2024 16:27:25 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Christian Ebner , Proxmox Backup Server development discussion References: <20240305092703.126906-1-c.ebner@proxmox.com> <20240305092703.126906-10-c.ebner@proxmox.com> <1710162739.scaemiackd.astroid@yuna.none> <883428477.10855.1710166942215@webmail.proxmox.com> In-Reply-To: <883428477.10855.1710166942215@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1710170552.cfuyuw2qf0.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.065 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [RFC v2 pxar 09/36] encoder: add payload advance capability X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2024 15:28:03 -0000 On March 11, 2024 3:22 pm, Christian Ebner wrote: >> On 11.03.2024 14:22 CET Fabian Gr=C3=BCnbichler wrote: >>=20 >>=20 >> so isn't this in fact a PayloadOffset then (like it is returned as in >> the corresponding getter)? and isn't the size then actually another >> offset as well? would maybe make it easier to avoid "holding it wrong" >> (i.e., passing in some other u64), or at least, force to wrap it in >> PayloadOffset which hopefully entails double-checking that that makes >> sense ;) >>=20 >=20 > No, this is actually the size to advance the position of the payload stre= am by > when injecting reused chunks, so the caller will pass the total size of t= he > injected chunks. what I mean is - when you read this you encode it as PayloadOffset. when you advance it to skip (ahead) to a certain offset, it's now a regular u64. I know the (only) input here (at the moment!) is chunk size(s), but what effectively happens is you tell the encoder "advance by offset X", so we might as well mark it as such in the interface, and force callers to think "hey, does it make sense to cast/wrap the u64 I have here as an offset in payload context?" (which it does when we want to let the encoder skip ahead by X chunks) > I was thinking of adding the chunks themself as parameters, this would ho= wever > require to expose that type to the pxar crate, so I opted for keeping thi= s as > unsigned integer. Maybe I should construct a dedicated type just for this= ? I think it's fine to just pass the value by which we want to advance, I just wonder whether it doesn't make sense to refer to it as PayloadOffset across the board and internally, to make it clear at the pxar <-> rest interface what meaning this u64 has, to avoid confusing it with the other (wrapped or unwrapped) u64 values we have all around.