Re: [PATCH v7 3/8] gpu: nova-core: add TLV parser for firmware files
Timur Tabi <[email protected]>
| Newsgroups | dev.linux.lists.driver-core,dev.linux.lists.nova-gpu,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 2026-08-04 at 00:21 +0200, Danilo Krummrich wrote: > > Well, maybe this is where we should return ENODATA? > > Or maybe just ENOENT. > > > I am expecting future Nova code to handle tags that may be legitimately absent, so maybe > > having > > it return ENODATA if the tag is missing, and EINVAL in all other situations is better. > > In this case it makes sense to differenciate; AFAIC this can be a follow-up > patch. ... > This is what I refer to below as "signed tag". > > Some background on this: We can't have patches as duplicate commits going to > Linus. So in order for me to pull from the Rust tree, it has to guarantee to not > change its histroy (which it does not). Besides that, we don't want all the > commits from another tree, but just a specific one. The normal process for this > is to put the commit on a separate branch based on a commit base, e.g. some -rc, > typically -rc1. Then we can create a signed tag from this that can be merged > into both (or multiple) trees, so the commit only exists exactly once. > > However, this kind of logistics typically only makes sense for features, etc. In > order to avoid a trivial conflict, it is usually overkill. Which is also why I > said I'd go for the former. How about this: replace all ENODATA with EINVAL in this patch for now, and then after drm-rust- next pulls in my error.rs change from the Rust tree, I replace some of those EINVAL with ENOENT or ENODATA.