From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 253995A0304 for ; Fri, 17 May 2024 13:01:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715943714; h=from:from:reply-to:subject:subject: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=QM2aAFf0wFGlNM0FyOHQuS6XWUDeqFVVVLHkbXQ4bi0=; b=TZnPaWetZcOUi/IF7dBmsZ3yD/lNt8YpNgdnPEkCaeQs2zFIBBKeRGTx0aYbGMrOPFZF3Q EhCwmuQCZGf25VfWdwoEqgN1OSqwkgzN8LdJ5EA5wbVcw5MmPlqmeR6aTcMOgLXRIGOtLq O9AbiQ1CeOS3nJ95iGziVpWEKI2+pps= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-AjbvqtabObej0dg749KiSQ-1; Fri, 17 May 2024 07:01:52 -0400 X-MC-Unique: AjbvqtabObej0dg749KiSQ-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a5a05c4e0efso567965466b.1 for ; Fri, 17 May 2024 04:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715943711; x=1716548511; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QM2aAFf0wFGlNM0FyOHQuS6XWUDeqFVVVLHkbXQ4bi0=; b=dDmJ4PRvBoSDktwI37VF2InhkTXWbab4SKmxGp0ty3G0x80qXvYTEBtWP2japRJyZv TTESFAd276QHgmac78Z8tdcrc/8RsnGVAGuX69K/UFBFEfCKTvmEf2t8JF87mnsXSZkZ LJ5v1yr/VbtzeK2DbzQYMxCjjYvwRRRFmxiTDVkydRbgrI1fr9d+kX45bIsYzEGIaLD1 yw5IbmFGkWcpDrl0kZXerGPQogP/BszXZQx4dtYyEOTv/UaRYxgFC8vX2nbJTmuXUSTV gRqlkJPLh/b+s7o0cBJiIz2Gowum62fQyZxTv/1xFZoyLQqZlNSCiqYoOAub+wybL8s0 /1TA== X-Gm-Message-State: AOJu0Yzr4d7hgKOLxotEOgiqvTnAfkoeeJTMhxEqzlPDSp2u7DVDoQdY LzYudhxTud7eXAR90Zss8wRHf0FJcIbyzkas8LRikL2etEWY+L9mkjvnmKE7AdkhPqfh6PgB+7X kokAlIrG0r/HAFl51JitJ1er1Mt5a8mcN4XU60wO/QJYqP8A42Q== X-Received: by 2002:a17:906:6716:b0:a59:9e02:68fc with SMTP id a640c23a62f3a-a5a2d5f193dmr1461117866b.44.1715943710834; Fri, 17 May 2024 04:01:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFFJFz0VAFhso5ccQI8W2LV8LQZbhEUlrvm+a/FiHbVRDPv5b6dbCU3rwYeQvzeyZvgcMNQGg== X-Received: by 2002:a17:906:6716:b0:a59:9e02:68fc with SMTP id a640c23a62f3a-a5a2d5f193dmr1461114766b.44.1715943710113; Fri, 17 May 2024 04:01:50 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a5ce877ece2sm203970866b.13.2024.05.17.04.01.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2024 04:01:48 -0700 (PDT) Date: Fri, 17 May 2024 13:00:44 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v5 01/19] flow: Clarify and enforce flow state transitions Message-ID: <20240517130044.6bb8ce53@elisabeth> In-Reply-To: References: <20240514010337.1104606-1-david@gibson.dropbear.id.au> <20240514010337.1104606-2-david@gibson.dropbear.id.au> <20240516113058.1e8f0b66@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 23EK2UJTL5225KDQHGJNYLSRXQ55HUCQ X-Message-ID-Hash: 23EK2UJTL5225KDQHGJNYLSRXQ55HUCQ X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 17 May 2024 13:57:58 +1000 David Gibson wrote: > On Thu, May 16, 2024 at 11:30:58AM +0200, Stefano Brivio wrote: > > On Tue, 14 May 2024 11:03:19 +1000 > > David Gibson wrote: > > > > [...] > > > > > /** > > > * struct flow_common - Common fields for packet flows > > > + * @state: State of the flow table entry > > > * @type: Type of packet flow > > > */ > > > struct flow_common { > > > + uint8_t state; > > > > In this case, I would typically do > > (https://seitan.rocks/seitan/tree/common/gluten.h?id=5a9302bab9c9bb3d1577f04678d074fb7af4115f#n53): > > > > #ifdef __GNUC__ > > enum flow_state state:8; > > #else > > uint8_t state; > > #endif > > I don't object to that, but I have two questions > > - What's the advantage to using the explicit enum? Is that for the > benefit of static checkers and/or compiler diagnostics? Yes: if we assign a value that's not in the enum, I expect static checkers to complain. But also for humans: even with that ifdef, a reader would know right away what values that might have. > AFAIK C > itself doesn't really treat enums any differently to integer > types. Right. > - What's the need for GNUC? Are enum bitfields a gnu extension? They're rather permitted by gcc's interpretation of the standard: https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html Allowable bit-field types other than _Bool, signed int, and unsigned int (C99 and C11 6.7.2.1). Other integer types, such as long int, and enumerated types are permitted even in strictly conforming mode. but C11 says (6.7.2.1): A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. It is implementation-defined whether atomic types are permitted. Is an enum a "version" of those? Maybe not. That was at least the interpretation adopted by older gcc versions, up to 4.7.4: https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html Allowable bit-field types other than _Bool, signed int, and unsigned int (C99 6.7.2.1). No other types are permitted in strictly conforming mode. Did that change from C99? Not really: A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. > Even versus C11, which we already require? Yes, I would say it doesn't change things. Only C23 would improve that: https://open-std.org/JTC1/SC22/WG14/www/docs/n3030.htm#design-constant.type by allowing us to define the underlying type. > > ...and in any case we need to make sure to assign single values in the > > enum above: there are no guarantees that FLOW_STATE_ACTIVE is 3 > > otherwise (except for that static_assert(), but that's not its purpose). > > I'm not clear how this comment relates to the one before. It's unrelated, but: > AFAIK > nothing in here (or the rest of the series) relies on the specific > numeric values of the flow state values (although we do rely on them > being ordered as written in some places). while we rely on the fact that no value is bigger than 255, I realised that the standards already guarantee that values start from 0 and every subsequent constant is defined as one more than the previous one, all the way from C90 to C11, so this would actually be fine. Sorry, I don't know exactly why I thought that wouldn't be the case, I was pretty sure of the opposite until I checked. -- Stefano