|
From: Tim P. <ec...@ec...> - 2009-06-06 06:33:47
|
Hello,
Sorry if this is the wrong list to post this question.
I am working on some application that use the Xen low level interfaces.
Commonly, I'm seeing this:
==7203==
==7203== Warning: noted but unhandled ioctl 0x305000 with no
size/direction hints
==7203== This could cause spurious value errors to appear.
==7203== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing
a proper wrapper.
I've examined the docs/html/dist.readme-missing.html and adding hints
for xen hypercalls and other ioctls (for Xen privcmd) seems very
straight forward, at least for Linux.
I have several questions before I begin:
1 - Is syswrap-generic.c (in PRE(sys_ioctl) and POST(sys_ioctl)
respectively) the right place for these? That's where _NR_ioctl is
handled for everything from what I can see. If they should be broken out
into another module, I'll need some guidance :)
2 - I should VKI namespaceize the few constants and structures needed
and add them in include/vki/vki-{arch}.h? I noted the presence of
_VKI_IOC() in both x86 and amd64. Since these aren't coming out of
linux, would it be appropriate to put them in vki-virt-{arch}.h and
include them in vki-{arch}.h ?
3 - Is there any reason why these were not added as of yet, i.e. was the
issue of Xen being a moving target a problem? While Xen may add more
ioctls in the future, the existing will not change.
4 - Where should I post a RFC for the patch prior to creating a bug and
attaching it, or should I just upload it?
It seemed almost too easy, so I want to be sure I'm not missing
something.
Thanks for making and maintaining such a very useful tool!
--Tim
|
|
From: Nicholas N. <n.n...@gm...> - 2009-06-06 07:49:31
|
On Sat, Jun 6, 2009 at 4:33 PM, Tim Post<ec...@ec...> wrote: > > Sorry if this is the wrong list to post this question. The valgrind-developers list is arguably more suitable, but this is fine. > 1 - Is syswrap-generic.c (in PRE(sys_ioctl) and POST(sys_ioctl) > respectively) the right place for these? That's where _NR_ioctl is > handled for everything from what I can see. If they should be broken out > into another module, I'll need some guidance :) Looks like you're not looking at the SVN trunk code. You should, see http://www.valgrind.org/downloads/repository.html. PRE/POST(sys_ioctl) are the right functions, but they've moved into syswrap-linux.c. > 2 - I should VKI namespaceize the few constants and structures needed > and add them in include/vki/vki-{arch}.h? I noted the presence of > _VKI_IOC() in both x86 and amd64. Since these aren't coming out of > linux, would it be appropriate to put them in vki-virt-{arch}.h and > include them in vki-{arch}.h ? I would say "yes", but I'm not sure what you mean by "these aren't coming out of linux"? Are they not defined in the kernel headers? > 3 - Is there any reason why these were not added as of yet, i.e. was the > issue of Xen being a moving target a problem? While Xen may add more > ioctls in the future, the existing will not change. No, it'll just be because nobody's complained about them being missing before. > 4 - Where should I post a RFC for the patch prior to creating a bug and > attaching it, or should I just upload it? Just create a bug for it: http://www.valgrind.org/support/bug_reports.html. > It seemed almost too easy, so I want to be sure I'm not missing > something. No, adding new ioctl constants is pretty easy. Nick |
|
From: Tim P. <ec...@ec...> - 2009-06-06 08:38:34
|
On Sat, 2009-06-06 at 17:49 +1000, Nicholas Nethercote wrote: > On Sat, Jun 6, 2009 at 4:33 PM, Tim Post<ec...@ec...> wrote: > > > > Sorry if this is the wrong list to post this question. > > The valgrind-developers list is arguably more suitable, but this is fine. > > > 1 - Is syswrap-generic.c (in PRE(sys_ioctl) and POST(sys_ioctl) > > respectively) the right place for these? That's where _NR_ioctl is > > handled for everything from what I can see. If they should be broken out > > into another module, I'll need some guidance :) > > Looks like you're not looking at the SVN trunk code. You should, see > http://www.valgrind.org/downloads/repository.html. > PRE/POST(sys_ioctl) are the right functions, but they've moved into > syswrap-linux.c. Thanks. I was going to grab the trunk before I started, I was examining the latest release sourceball as I need to patch both. > > > 2 - I should VKI namespaceize the few constants and structures needed > > and add them in include/vki/vki-{arch}.h? I noted the presence of > > _VKI_IOC() in both x86 and amd64. Since these aren't coming out of > > linux, would it be appropriate to put them in vki-virt-{arch}.h and > > include them in vki-{arch}.h ? > > I would say "yes", but I'm not sure what you mean by "these aren't > coming out of linux"? Are they not defined in the kernel headers? No, Xen defines them in its own header after including the appropriate bits from the kernel. That is why I was considering placing these in a separate file. It could be included in vki-{arch}.h anywhere after the vki namespaceized types are defined, probably before the first one from Linux. I need 3 structures that depend on 2 others, so I wanted to isolate the clutter. Or, I can just toss them in at the end of each, whichever you'd like. Thanks again! Cheers, --Tim |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-06 21:52:32
|
On Sat, Jun 6, 2009 at 6:38 PM, Tim Post<ec...@ec...> wrote:
>> > 2 - I should VKI namespaceize the few constants and structures needed
>> > and add them in include/vki/vki-{arch}.h? I noted the presence of
>> > _VKI_IOC() in both x86 and amd64. Since these aren't coming out of
>> > linux, would it be appropriate to put them in vki-virt-{arch}.h and
>> > include them in vki-{arch}.h ?
>>
>> I would say "yes", but I'm not sure what you mean by "these aren't
>> coming out of linux"? Are they not defined in the kernel headers?
>
> No, Xen defines them in its own header after including the appropriate
> bits from the kernel. That is why I was considering placing these in a
> separate file. It could be included in vki-{arch}.h anywhere after the
> vki namespaceized types are defined, probably before the first one from
> Linux.
>
> I need 3 structures that depend on 2 others, so I wanted to isolate the
> clutter.
>
> Or, I can just toss them in at the end of each, whichever you'd like.
Hmm, I'd say to just chuck them at the end with an appropriate
explanatory comment.
Nick
|