Hi Peter,
On Thu, Dec 21, 2023 at 9:13 AM Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
Hmm I don't know, but I wonder why I am not just checking t->bios_ver for Unknown. I'll have a look and change it
Ok, this can't be changed as easily. smbios_add_prop() will not return NULL in any case. It returns an integer. With the cleanup, it will always writes 'Uknown' and not return 0 anymore. I can add that default value you suggested but the ctx->last_str is still used on the next line anyway.
Would you mind if I tried to create a version of the patch which does the same thing but with less code, and perhaps a test? It might be easier to discuss it then. I can't claim to understand all the different code paths at this point.
My main concern is that with so many code paths it will be hard even to refactor the code in the future, since it will become 'load-bearing' and anyone might turn up and say it breaks their board because different information is provided.
I don't buy this argument at all, sorry.
OK.
Overall, so long as the information isn't used for anything important in userspace, and we find a way to report SMBIOS to Linux without EFI,
No, you can't tie random requirements to improving the SMBIOS support. We *already* report SMBIOS to Linux, reporting SMBIOS to Linux without EFI is changing things that will need different or extra standards, that could take years.
You are arbitrarily adding extra requirements just to suite yourself, please STOP trying to hold things like this hostage.
Isn't that what is happening with Linux and ffi? My understanding is that there is no way to pass SMBIOS to Linux without EFI. Is that correct? I know some people at their wit's end about that.
Maybe the uses that want to go from a minimal firmware straight to a minimal kernel don't care about SMBIOS tables for their use cases, things don't need to be full parity to move forward the existing well defined usecase.
Yes, maybe.
You may know that I have tried for years to get bindings upstream to Linux....right now there is a reserved-memory binding which has been held up for longer than I can remember, because of EFI. How about a little give and take?
I actually caught up on the reserved-memory binding thread a week or so ago and my general thoughts from that thread was that there was a lot of outstanding questions being asked of you that you haven't clearly articulated or even replied to and the thread ended with you asking a number of times "can this be merged now?" and my thought at the time was "No, because there's a bunch of outstanding details". May I suggest you re-read that thread and take some notes while you do so and make sure all the outstanding questions have been answered and reply with a single response addressing the remaining details, from there we may be able to move on.
Note that I am just the facilitator for the binding. I volunteered to send it since I have some knowledge and experience with devicetree. I believe (from reading the thread) that at least Rob understood the use case, but has no interest in it. At one point he asked for buy-in from Tianocore/EDK2 people - they were already on cc but then started trying to answer the questions.
Also note that it has been 3 months since v7 was sent. I have just gone through the thread again. I don't see a "bunch of outstanding details". I do see a some EDK2-specific questions, if that is what you mean, but I don't know enough to answer those. The deep discussion of EDK2-specific implementation details worries me, actually, since the whole point of UPL is to be able to swap out the Platform Init and Payload.
Conceptually the binding is simple...if we need another node with a phandle we can do that. But why is it getting so stuck in the weeds?
If you think you can help on that thread, please do.
[..]
Regards, Simon