On 1/20/20 9:20 PM, Frank Rowand wrote: > On 1/20/20 12:28 PM, Steve McIntyre wrote: >> Hi Frank! >> >> Thanks for the link back to the previous discussion, it's very >> helpful. >> >> On Mon, Jan 20, 2020 at 10:14:22AM -0600, Frank Rowand wrote: >>> On 1/20/20 4:56 AM, Alexandre Torgue wrote: >> >> ... >> >>>> and the date). There are no "dtb versions", and "absolute/relative" >>>> path which created concerns. One remaining concern is "reproducible >>> >>> Here is an example of the info from one of my builds: >>> >>> From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. >>> >>> The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected >>> to in my proposal. >> >> ACK. :-( I'm surprised to see so much push-back on what looks like a >> simple piece of information here. > > Me too. > > >> >> I've had users *specifically* asking for this kind of identification >> so that they can verify the version of the DTB they're using at >> runtime. Right now it can be a guessing game, which does not help >> people trying to debug problems. >> >> Cheers, >> > > If the information was reported as debug information via pr_debug(), > would that work for your use case? Or would the users' kernels > not have debug enabled in the configuration? And even pr_debug() might not be sufficient since the property value is available via /proc/device-tree if the proc file system is enabled.
