<div dir="ltr"><div>Hi!<br></div><div><snip><br></div><div>>And this one languished for a week. Unintentional irony, sorry. (I was<br>
>debugging sed.)<br>
<span class="im">It's okay, I ran into life as well<br><br>
</span>>My general plan for making "run as root" tests work is to make an<br>>Aboriginal Linux build control image that runs them as root under qemu.<br>
><br>>  <a href="http://landley.net/aboriginal/control-images" target="_blank">http://landley.net/aboriginal/control-images</a><br>
I'll have to try this out some time :)<br></div><span class="im"><snip><br><br></span><div><span class="im">
</span>>Ah, I remember why this went on the todo list. This includes 22 test<br>
>cases, to be run as root, with no indication of what the actual bug is<br>
>or which test case hits it. What does failure look like? What would<br>
>success look like?<br>
Tried to add more explanatory notes.<br><br>My concern with ifconfig down is that the interface that is down is still displayed with a call to ifconfig (as opposed to ifconfig -a)<br><br>My main concern with calling the pointtopoint option is it returns a usage message instead of making the changes to the ifconfig display that nettools makes when given the same command. (I'm not sure what the reference should be, so I went with what Kali does).<br></div><div><br>>This test set relies on modprobing a "dummy" module, and my normal test<br>
>environment for this sort of thing is a static kernel built without<br>
>module support.<br></div><div>Removed the modprob call, and it still seems to work on Kali...<br></div><div>
<br></div><div><snip><br></div><div>>Running ifconfig tests remotely through the network<br>
>is... awkward.<br>Does that mean the overall testing strategy of the testsuite might be good for now?<br><br></div><div>>I can fire up an ubuntu instance under kvm, maybe? Or add the DUMMY<br>
>kconfig symbol to the aboriginal kernel I build and modify the test not<br>
>to modprobe.<br></div><div>
Looks like removing modprobe fixed the issue on Kali (it just feels really wrong)...<br></div><div>>Let me get back to this after I cut the 0.5.1 release...<br>
OK.  Looking forward to your feedback on this patch.<br></div><div>Thanks,<br></div><div>Cindy<br></div><div><br>
> Thanks,<br>
> Cindy<br>
<br>
>Sorry this is taking so long, juggling many things.<br></div><div>It's okay, this is just a hobby for me.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 5:38 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/12/14 20:48, Cynt Rynt wrote:<br>
> Hi,<br>
> Thanks for getting back to me so quickly.<br>
<br>
</span>And this one languished for a week. Unintentional irony, sorry. (I was<br>
debugging sed.)<br>
<span class=""><br>
> I was trying to figure out<br>
> how to write coverage tests for toybox, and ran into issues using the<br>
> pointtopoint option for ifconfig.<br>
<br>
</span>My general plan for making "run as root" tests work is to make an<br>
Aboriginal Linux build control image that runs them as root under qemu.<br>
<br>
  <a href="http://landley.net/aboriginal/control-images" target="_blank">http://landley.net/aboriginal/control-images</a><br>
<br>
(That's why chgrp.test and losetup.test have the "not root" part at the<br>
beginning.)<br>
<br>
It's on the todo list. :)<br>
<span class=""><br>
> Before I finished writing the test<br>
> suite, I thought it best to find out if I was calling ifconfig wrong or<br>
> if I found a bug.  Attached is the .patch that generated the issue.<br>
<br>
</span>Ah, I remember why this went on the todo list. This includes 22 test<br>
cases, to be run as root, with no indication of what the actual bug is<br>
or which test case hits it. What does failure look like? What would<br>
success look like?<br>
<br>
This test set relies on modprobing a "dummy" module, and my normal test<br>
environment for this sort of thing is a static kernel built without<br>
module support. I'm reluctant to test it on my netbook because according<br>
to uptime the last time I rebooted was August. (I don't care about the<br>
uptime value, I've been meaning to reboot the thing so youtube starts<br>
working again anyway (ubuntu upgraded the video codecs out from under<br>
the browser, and apparently relaunching chrome isn't good enough, it<br>
wants a reboot).) But I have eight desktops full of open windows, most<br>
with multiple tabs, and ps ax | wc -l says 491 processes, so I have to<br>
go through and close a lot of tabs before I can reboot without losing<br>
track of what I'm working on. I'd rather avoid a forced reboot when I'm<br>
not ready to spend the rest of the day doing state cleanup.<br>
<br>
Testing this on the other machine is problematic because although it's<br>
technically a laptop, the battery lasts 15 seconds, so it's on a shelf<br>
and I ssh into it to use it. (ssh -X and x11 forwarding actually work<br>
reasonably well...) Running ifconfig tests remotely through the network<br>
is... awkward.<br>
<br>
I can fire up an ubuntu instance under kvm, maybe? Or add the DUMMY<br>
kconfig symbol to the aboriginal kernel I build and modify the test not<br>
to modprobe.<br>
<br>
Let me get back to this after I cut the 0.5.1 release...<br>
<br>
> Thanks,<br>
> Cindy<br>
<br>
Sorry this is taking so long, juggling many things.<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br></div>