From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E1DAC1FF391 for ; Wed, 12 Jun 2024 14:49:32 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 295F110A0C; Wed, 12 Jun 2024 14:50:09 +0200 (CEST) Date: Wed, 12 Jun 2024 14:49:35 +0200 From: Wolfgang Bumiller To: Shannon Sterz Message-ID: References: <20240610154214.356689-1-s.sterz@proxmox.com> <20240610154214.356689-5-s.sterz@proxmox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.093 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] [PATCH proxmox 4/5] access: factor out user config and cache handling 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: , Reply-To: Proxmox Backup Server development discussion Cc: pbs-devel@lists.proxmox.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On Tue, Jun 11, 2024 at 04:30:25PM GMT, Shannon Sterz wrote: > On Tue Jun 11, 2024 at 3:07 PM CEST, Wolfgang Bumiller wrote: > > On Mon, Jun 10, 2024 at 05:42:13PM GMT, Shannon Sterz wrote: > > > this commit factors out the user config as well as the shared memory > > > based config version caching mechanism. this makes it necessary that > > > users of this crate provide the product name and a reference to a > > > shared memory location as well. > > > > Given that we have more values in the shared memory in PBS I wonder if > > we should instead provide the `get` and `increment` methods to init > > (directly as `fn` or via a trait). > > yeah, that might make sense to hand that over via a trait and implement > the actually shared memory portion either in the project itself or have > a generic implementation that we can adapt to each project. not entirely > sure what the best way is, though. > > if we do implement some kind of generic shared memory cache generation > counter, where would live ideal? Depends on what it does. As long as we only need simple counters, the crate could just expose them as an array filling the allocated 4k with the users defining indices for their counters. I doubt we'll need more than what we can fit in there for now ;-) _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel