diff --git a/bazel/example/WORKSPACE.bazel b/bazel/example/WORKSPACE.bazel index 6ea194c3..074d6ed2 100644 --- a/bazel/example/WORKSPACE.bazel +++ b/bazel/example/WORKSPACE.bazel @@ -1,29 +1,19 @@ load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository") load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") +# In your own project, you will likely want to use `http_archive` instead +# of `local_repository` to load p4runtime. local_repository( name = "com_github_p4lang_p4runtime", path = "../../proto", ) - -# In your own project, you will likely want to use `http_archive` or -# `git_repository` instead of `local_repository` to load p4runtime. - # http_archive( # name = "com_github_p4lang_p4runtime", -# urls = ["https://github.com/p4lang/p4runtime/archive/v1.4.0.tar.gz"], -# strip_prefix = "p4runtime-1.4.0/proto", +# urls = ["https://github.com/p4lang/p4runtime/archive/v1.4.1.tar.gz"], +# strip_prefix = "p4runtime-1.4.1/proto", # # sha256 = "", # ) -# git_repository( -# name = "com_github_p4lang_p4runtime", -# remote = "https://github.com/p4lang/p4runtime.git", -# # strip_prefix = "proto", # https://github.com/bazelbuild/bazel/issues/10062 -# patch_cmds = ["mv proto/* ."], # Workaround since strip_prefix is broken. -# tag = "v1.4.0", -# ) - load("@com_github_p4lang_p4runtime//:p4runtime_deps.bzl", "p4runtime_deps") p4runtime_deps() diff --git a/docs/v1/P4Runtime-Spec.mdk b/docs/v1/P4Runtime-Spec.mdk index 6c49c7f2..26319476 100755 --- a/docs/v1/P4Runtime-Spec.mdk +++ b/docs/v1/P4Runtime-Spec.mdk @@ -1,5 +1,5 @@ Title : P4Runtime Specification -Title Note: version 1.4.0-dev +Title Note: version 1.4.1 Title Footer: &date; Author: The P4.org API Working Group Heading depth: 5 diff --git a/docs/v1/guidance-for-generating-p4info.md b/docs/v1/guidance-for-generating-p4info.md index e1eb93ec..7f721e2d 100644 --- a/docs/v1/guidance-for-generating-p4info.md +++ b/docs/v1/guidance-for-generating-p4info.md @@ -38,7 +38,7 @@ representing the name of the library, its major version, etc. ## Handling P4_16 `type` and the `p4runtime_translation` annotation -The P4Runtime v1.3 specification restricts the types that it supports +The P4Runtime v1.4 specification restricts the types that it supports for the following kinds of things: + table search key fields, defined in the P4Info message in a @@ -54,13 +54,13 @@ for the following kinds of things: Later in this section, we will use the term "constrained value" for brevity, instead of repeating all of the kinds of objects listed -above. For such values, the P4Runtime specification v1.3 supports all +above. For such values, the P4Runtime specification v1.4 supports all of the following types, but currently no others: + `bit` + an `enum` with an underlying type of `bit`, also called a serializable `enum` (TBD whether all of the pieces needed to make - this work are actually supported for P4Runtime 1.3) + this work are actually supported for P4Runtime 1.4) + a `typedef` or `type` name that, when "followed back" to the lowest base type, is one of the above. (As of the P4_16 language specification version 1.2.1, it is not required to support a `type` @@ -100,7 +100,7 @@ type_list(x) { Note that `type_list(x)` always starts with zero or more `type` names, and always ends with one type that is neither a `type` nor `typedef` name, e.g. `bit`, a header type, struct type, etc. It never -contains the name of a type declared using `typedef`. P4Runtime v1.3 +contains the name of a type declared using `typedef`. P4Runtime v1.4 only supports `p4runtime_translation` annotations on `type` definitions. If any such annotations occur on a `typedef` definition, they should be ignored. @@ -111,7 +111,7 @@ of type names. In order to create such a cycle, the first `type` or type name, and this is not allowed. If the last type is not `bit` or `enum bit`, that is an error -for P4Runtime v1.3. The "base" type must always be one of those for +for P4Runtime v1.4. The "base" type must always be one of those for every constrained value.