Em Thu, 27 Oct 2016 16:51:22 -0600 Jonathan Corbet <corbet@xxxxxxx> escreveu: > On Wed, 26 Oct 2016 21:14:00 -0200 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> wrote: > > > On a very quick look on the document, it seems that the legacy info > > there are at this section of the document: > > > > - Finding it the old way > > > > IMHO, we can strip that section completely. > > At least we agree on that part. > > > The git bisect section is too small to my taste, as, IMHO, the best would > > be if it would be telling about the process, e. g. pointing or C/C the > > contents of articles like: > > Too small? Mauro, it's six lines, one of which reads, in its entirety, > "have fun" :) Heh ;) > The stuff you propose adding is good, but is it really > better than saying "read the git-bisect man page"? That page is pretty > clear, especially by the standard of git man pages :) Yeah, git bisect man page is good, but let me take one step back and explain my selfish desire on having it documented, and check if we're at the same page ;-) The main reason I jumped into user and process doc conversion is that, every time someone has problems reporting bugs or submitting patches, I need to seek at the Internet and point to some place that would help him to proceed. Ok, I answer the guy to read the man page, but this could sound unpolite ;) Also, a newbie may not have it installed, or have some other problem, with would take me more time to explain what I meant. So, I prefer to point them to: read this URL: http://foo/doc, as I can verify what's there and be sure that it will solve the issue. So, at least the way I see, I prefer to have a quick and dirty instructions there, with some html references pointing to more detailed explanations, as I know that the bare minimum is documented, and if the user still has doubts, he can jump into a detailed explanation. > > > What do you think about the patch below? I double-checked the > > "Fixing the bug" part, and what is there makes sense for me. > > I changed it a little bit to make it easier for newbies. > > Not sure; when's the last time the objdump stuff was really relevant to > you? In my case, I always compile kernels with DEBUG_INFO enabled, so I only use gdb to get the source lines when an OOPS happens. Yet, from time to time, ARM users report bugs there, with Kernels compiled without DEBUG_INFO. For such users, objdump is interesting. > I can certainly see the value of a proper "how to debug the kernel" > guide, talking about the *many* facilities we have for kernel debugging at > this point. This document isn't that. Good point. Do you have any suggestions about what else should be included? Looking on what we've converted already, IMHO, we could put on such guide: https://mchehab.fedorapeople.org/kernel_docs/admin-guide/dynamic-debug-howto.html https://mchehab.fedorapeople.org/kernel_docs/dev-tools/kasan.html And perhaps add a guide about the Kernel Hacking options at the Kconfig menu. Anything else? I can try to draft something to add there after KS. > I've dropped my deletion patch from the series for now (will likely apply > the rest shortly), but I still think we need to be more willing to dump old > stuff that we can't maintain properly. OK, thanks! The rest are OK from my side. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
