From: Andi Kleen <andi@firstfloor.org>
To: Hui Zhu <teawater@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Geoff Levand <geoff@infradead.org>,
jason.wessel@windriver.com
Subject: Re: [PATCH]KGTP (Linux Kernel debugger and tracer) lite patch for review
Date: Thu, 24 May 2012 17:07:54 +0200 [thread overview]
Message-ID: <20120524150754.GF27374@one.firstfloor.org> (raw)
In-Reply-To: <4FBE3938.30000@gmail.com>
> I remove them from asm files, and add:
> #ifndef ULONGEST
> #define ULONGEST uint64_t
> #endif
> #ifndef CORE_ADDR
> #define CORE_ADDR unsigned long
> #endif
> in gtp.c
> Then if not need, the arch didn't define ULONGEST and CORE_ADDR for itself.
Which architecture needs it? Linux prefers to use "native" types.
> For example ARM and MIPS have a lot of special reg that cannot be converted
> by a for loop.
>
> After check the code the kgdb, I thought that good ways is use dbg_reg_def
> of kgdb to convert the reg to gdb rsp format. But use it directly will
> make kgtp depend on kgdb.
That's fine. Code reuse is good. Code duplication is bad.
> What I thought is move this part of code out from kgdb, when kgdb or kgtp
> need, select it too. But I am not sure Jason is OK with that.
Just send a patch.
> >
> >>+ memcpy(&freg->regs, regs, sizeof(struct pt_regs));
> >>+#ifdef CONFIG_X86_32
> >>+ freg->regs.sp = (unsigned long)®s->sp;
> >>+#endif /* CONFIG_X86_32 */
> >>+#ifdef CONFIG_X86
> >>+ freg->regs.ip -= 1;
> >>+#endif /* CONFIG_X86 */
> >
> >What is that for? - 1?
>
> That is because when kprobe, the ip of X86 point will have a offset with
> current ip.
But a kprobe is not necessarily one byte. e.g. a jumper probe is longer.
Anyways if that is really needed there should be some macros provided
by kprobes to adjust IP. If it's not there it needs to be added.
> >>+
> >>+ if (gtp_start)
> >>+ return -EBUSY;
> >
> >This is in a lot of places. Can you put it somewhere more central?
>
> Sorry I don't understand this part. Do you want I change all "struct
> gtp_entry *tpe;" to "struct gtp_entry *tpe;"?
I mean the if (gtp_start) return -EBUSY check.
> >
> >>+ pr_devel("gtp_gdbrsp_QT: %s\n", pkg);
> >>+
> >>+ if (strcmp("init", pkg) == 0)
> >>+ ret = gtp_gdbrsp_qtinit();
> >
> >This if cascade should be probably a table walk
>
> I cannot find the examle about it in the Kernel, could you give me a
> example?
struct cmd {
char *name;
int (*init)(void);
};
struct cmd cmds[] = {
{ "init", gtp_xyz_init }
...
{}
};
int i;
for (i = 0; cmds[i].name; i++)
if (!strcmp(cmds[i].name, pkg))
ret = cmds->init();
> >Ok so what lock protects this buffer?
>
> No. The gtp_frame_lock protects the vars that follow it:
> static int gtp_frame_num;
> static char *gtp_frame;
> static char *gtp_frame_r_start;
> static char *gtp_frame_w_start;
> static char *gtp_frame_w_end;
> static char *gtp_frame_r_cache;
> static int gtp_frame_is_circular;
> It protects them all.
>
> gtp_m_buffer is protected by gtp_rw_lock that I just add in new patch.
Then your comment was wrong/unclear?
>
>
> OK. Add some introduce. checkpatch is OK with it.
You must be using an old version?
# check for Kconfig help text having a real description
# Only applies when adding the entry originally, after that we do not have
# sufficient context to determine whether it is indeed long enough.
...
WARN("CONFIG_DESCRIPTION",
"please write a paragraph that describes the config symbol fully\n" . $herecurr) if ($is_start && $is_end && $length < 4);
I wonder how you avoided that.
-Andi
next prev parent reply other threads:[~2012-05-24 15:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 7:14 [PATCH]KGTP (Linux Kernel debugger and tracer) lite patch for review Hui Zhu
2012-05-09 14:05 ` Andi Kleen
2012-05-10 12:15 ` Hui Zhu
2012-05-10 17:38 ` Andi Kleen
2012-05-24 13:35 ` Hui Zhu
2012-05-24 15:07 ` Andi Kleen [this message]
2013-11-21 5:05 ` Hui Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120524150754.GF27374@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=geoff@infradead.org \
--cc=hch@infradead.org \
--cc=jason.wessel@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox