On Wed, Sep 19, 2018 at 08:05:31AM -0400, Prarit Bhargava wrote: > On 09/18/2018 07:47 PM, Daniel Thompson wrote: > > On Tue, Sep 18, 2018 at 08:21:09AM -0400, Prarit Bhargava wrote: > >> On 09/17/2018 07:36 PM, Daniel Thompson wrote: > >>> On Mon, Sep 17, 2018 at 07:08:44PM -0400, Prarit Bhargava wrote: > >>>> > >>>> > >>>> On 09/17/2018 06:46 PM, Daniel Thompson wrote: > >>>>> On Tue, Sep 11, 2018 at 01:29:42PM -0400, Prarit Bhargava wrote: > >>>>>> As a test I hacked the buffer size to 16 and entered kdb: > >>>>>> > >>>>>> [16]kdb> > >>>>>> 117661 symbols are found. But only first 30 symbols will be printed. > >>>>>> You can change the environment variable DTABCOUNT. > >>>>>> irq_stack_union __per_cpu_start cpu_debug_store cpu_tss_rw gdt_page > >>>>>> exception_stack... entry_stack_sto... espfix_waddr espfix_stack > >>>>>> cpu_llc_id cpu_llc_shared_... cpu_core_map cpu_sibling_map cpu_info > >>>>>> cpu_number this_cpu_off x86_cpu_to_acpi... x86_cpu_to_apic... > >>>>>> x86_bios_cpu_ap... sched_core_prio... cpu_loops_per_j... pmc_prev_left > >>>>>> cpu_hw_events bts_ctx insn_buffer pt_ctx xen_vcpu_info xen_vcpu_id > >>>>>> xen_vcpu mc_buffer ... > >>>>> > >>>>> I don't quite understand what is being tested here (I thought the code > >>>>> you changed was only reached after tab is pressed twice) and you haven't > >>>>> shared what conclusion you have drawn from this test. > >>>>> > >>>> Hi Daniel, my apologies. Here's a more detailed explanation. > >>>> > >>>> I didn't feel comfortable submitting the code without testing and the > >>>> problem is > >>>> that I couldn't think of a kernel symbol that was 128 bytes in size that > >>>> would > >>>> be truncated so that ellipses would be printed out. What I decided to > >>>> do is > >>>> apply my patch *and* change the buffer size to 16, then rebuilt the > >>>> kernel, > >>>> booted the kernel, and selected the ttyS0 as the buffer console. I > >>>> entered kdb > >>>> using "echo g > /proc/sysrq-trigger" and hit tab twice to test the code. > >>>> > >>>> The above output confirms that the code is working as expected. Any > >>>> symbol > >>>> larger than 15 is truncated and appended with ellipses, for example > >>>> "cpu_llc_shared_...". Symbols smaller than 15 are fully output, for > >>>> example, > >>>> cpu_llc_id. > >>>> > >>>> IOW, it looks like the code works as expected. > >>> > >>> I cannot replicate the ellipsis behaviour my filling the read buffer > >>> until it is full (256 character command) and then deleting a few > >>> characters and then trying to tab complete. > >>> > >>> I'm not sure if I have misunderstood the code or your test! Can you > >>> share the change you made for testing as a patch? > >>> > >> > >> Sure ... sorry for the cut-and-paste but it's a one line patch. > > > > Ok. That was what I thought but I cannot reproduce this behaviour (which > > is hardly suprising since I cannot find any code to issue an ellipsis). > > > > Forgive my asking... I'm at a conference so I'm both busy and slightly > > jet lagged so the mistake could easily be on my side, but is there any > > chance you have written a v2 patch but not posted it to the ML yet ;-) ? > > > > > > :) Maybe I'm not doing it right. MAINTAINERS lists > "kgdb-bugreport@lists.sourceforge.net" as the mailing list, or do you want > this > patch to go to LKML?
Ok. I've gone back through the archive and realized what has happened... Your v2 patch wasn't formatted in the canonical way and I simply didn't notice that there was a new patch patch at the bottom. In particular because the subject line has not changed I assumed the patch at the bottom of the message had also not been changed. So... my inattention partially influenced this but it would better for you to send patches slightly differently. The descrption of a canonical patch is here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format Basically it would be good to move the info on testing into the non-description part of the patch header, add a changelog and update the subject with a v2 label. You also asked about To: and Cc: . I'm not personally super fussy about this but the most common approach is to put the people you expect to take action (e.g. Jason and myself) in To: and the various mailing lists and other interested folks in Cc:. In general you should copy both the sub-system mailing list *and* LKML. Anyhow... if you could resend v2 taking care of the above then that would be great! Daniel. _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
