Keir, I am sending a revised version of xenoprof including a few minor fixes and changes based on your comments. I was hoping you could push this into the public tree... I will be sending the 4 patches in 4 different messages. Thanks Renato _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I am sending a revised version of xenoprof including a few > minor fixes and changes based on your comments. > I was hoping you could push this into the public tree... > I will be sending the 4 patches in 4 different messages.It don''t think it makes sense to apply the linux part of these patches directly to the sparse tree -- the sparse tree should remain close to the vanilla base. Putting the patch into the patches/linux directory won''t work either as it touches files that are already in the sparse tree: the patch would need to be reverted before doing checkins. What''s probably best is if we check the patch into a tools/oprofile directory along with the user space tools. Have you had any feedback from the oprofile maintainer? Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Santos, Jose Renato G
2005-Nov-13 04:00 UTC
RE: [Xen-devel] [PATCH] xenoprof (linux-sparse)
Ian,
OProfile kernel driver has a generic code component and an architecture
specific code component (one for each of the OProfile supported
architectures). The generic code is located in the directory
"drivers/oprofile" of the linux tree. The architecture specific code
is
located on each architecture subtree (e.g. "arch/i386/oprofile" for
x86
and "arch/ia64/oprofile" for ia64). For xen we added a new
architecture
specific component (in "arch/xen/oprofile"). We also had to make a few
modifications in the generic code in "drivers/oprofile".
I agree that the modifications to the generic code in
"drivers/oprofile"
should not be included in the sparse tree. However, I thought that the
new architecture specific code in "arch/xen/oprofile" could be
included
in the sparse tree, since this is xen specific code and does not exist
in the vanila linux tree. That was the reason why I broke the linux
modifications into two patches (xenoprof-2.0-linux-2.6-sparse.patch and
xenoprof-2.0-linux-2.6.12.patch). I am not sure if I understand your
arguments against this option.
The patch for Oprofile user level tools could go to a "tools/oprofile"
directory or something equivalent as you suggested.
I also don''t understand why you would prefer to not include the patch
for the generic oprofile code ("drivers/oprofile") in the
patches/linux
directory. I don''t think they touch any file in the sparse tree as you
said. They only touch files in "drivers/oprofile" and
"include/linux/oprofile.h" which I believe are not in the sparse tree.
Maybe you were thinking about the old version of xenoprof which had all
linux modifications in a single patch.
Please let me know if you think this makes sense. I just wanted to make
sure you understand the xenoprof patches before deciding how to include
them.
Thanks
Renato
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt
Sent: Friday, November 11, 2005 6:15 PM
To: Santos, Jose Renato G; Keir Fraser
Cc: Turner, Yoshio; Jose Renato Santos; xen-devel@lists.xensource.com; G
John Janakiraman
Subject: RE: [Xen-devel] [PATCH] xenoprof (linux-sparse)
> I am sending a revised version of xenoprof including a few
> minor fixes and changes based on your comments.
> I was hoping you could push this into the public tree...
> I will be sending the 4 patches in 4 different messages.
It don''t think it makes sense to apply the linux part of these patches
directly to the sparse tree -- the sparse tree should remain close to
the vanilla base.
Putting the patch into the patches/linux directory won''t work either as
it touches files that are already in the sparse tree: the patch would
need to be reverted before doing checkins.
What''s probably best is if we check the patch into a tools/oprofile
directory along with the user space tools. Have you had any feedback
from the oprofile maintainer?
Thanks,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Sat, Nov 12, 2005 at 08:00:38PM -0800, Santos, Jose Renato G wrote:> The patch for Oprofile user level tools could go to a "tools/oprofile" > directory or something equivalent as you suggested.I''d much rather you send this patch to us and get it included rather than putting it somewhere else. Also, I don''t think the kernel bits should be applied until you''ve resolved the issues I had with the escape codes I mentioned a few months ago... it shouldn''t be hard to rework, right? regards, john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Santos, Jose Renato G
2005-Nov-13 18:45 UTC
RE: [Xen-devel] [PATCH] xenoprof (linux-sparse)
John, Thanks for your comments and suggetions.> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of John Levon > Sent: Sunday, November 13, 2005 4:41 AM > To: Santos, Jose Renato G > Cc: Ian Pratt; xen-devel@lists.xensource.com; Turner, Yoshio; > Jose Renato Santos; G John Janakiraman > Subject: Re: [Xen-devel] [PATCH] xenoprof (linux-sparse) > > On Sat, Nov 12, 2005 at 08:00:38PM -0800, Santos, Jose Renato G wrote: > > > The patch for Oprofile user level tools could go to a > "tools/oprofile" > > directory or something equivalent as you suggested. > > I''d much rather you send this patch to us and get it included > rather than putting it somewhere else. >Ok John. I will work on the changes you suggested in the next days and send you the user level tools patch.> Also, I don''t think the kernel bits should be applied until > you''ve resolved the issues I had with the escape codes I > mentioned a few months ago... it shouldn''t be hard to rework, right? >Right now we don''t need the escape codes. Those are used for supporting delivery of passive domain samples, ie. including an event sample from a domain without oprofile to another domain that has oprofile running. The escape codes are used to indicate a sample belongs to a different domain. The current version does not support passive domains, so we really don''t need the escape codes at the moment. I am planning to change the way passive samples are handled, so we won''t need escape code for that either, but this will require some more time (I am planning to use separate buffers for different domains, but I will have to discuss this in more detail with you later). Would you be happy if for now I remove the escape code completely? This should be easy to do. Thanks for your support Renato> regards, > john > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Nov 13, 2005 at 10:45:19AM -0800, Santos, Jose Renato G wrote:> The escape codes are used to indicate a sample belongs to a different > domain. The current version does not support passive domains, so we > really don''t need the escape codes at the moment.> Would you be happy if for now I remove the escape code completely? > This should be easy to do.Yes, I think so, if I remember rightly that was the only substantive complaint I had. regards, john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel