Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar: > On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o <tytso@xxxxxxx> > wrote: > > > > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote: > > > > > > I need to submit a patch to mainline which should be verified > > > against > > > linux-next tree with latest API. > > If you want to verify a patch that you intend to submit upstream, > > my > > suggestion is to *not* use linux-next, but rather use the latest > > tagged -rc from Linus's tree. So for example, you might want to > > use > > v4.14-rc2 as your base, and then apply your patch on top of v4.14- > > rc2. > > And then test v4.14-rc2. That way you don't need to worry about > > debugging problems that might be caused by code in other people's > > development trees. > > > > If you know which subsystem tree your commit is going to be sent > > to, > > you might use as your base the current development branch of that > > subsystem tree. But in general, it's fine to use something like > > v4.14-rc2; if the subsystem maintainer you plan to be submitting > > your > > patch has other preference, he or she will let you know, or take > > care > > of rebasing your patch onto his subsystme tree. > > > > > > > > My patch is related to some test utility based on client/server > > > model. > > > So, I need 2 terminal, one for server and one for client. > > That implies you're running the commands to run the test by > > hand. In > > the ideal world, tests should be automated, even those that are > > using > > client/server so that tests can be run unattended, over and over > > again. > > > > For example, here's an example of test involving a client and a > > server > > in xfstests: > > > > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g > > eneric/131 > > > > See? No terminal required, and certainly not two terminals! > > > > Remember, it's important not just to run one test, because the risk > > is > > that fixing one bug might cause a test regression somewhere > > else. So > > when I "validate" a kernel, I'm running thousands of tests, just to > > test the ext4 file system. For each bug that we fix, we try to add > > a > > new automated test, so we can be sure that some future change > > doesn't > > cause a bug to reappear. And if you're running hundreds or > > thousands > > of tests, you certainly aren't going to be wanting to manually set > > up > > each test by using putty to login to the VM using ssh! > > > > > > > > 1) How to resolve linux-next build error with ubuntu virtual box > > > 5.1.28 > > Virtual box is not relevant. What is relevant is the kernel config > > file you are using, and what compiler version / distro are you > > using > > to build the kernel. And as I said, you're better off using > > something > > like v4.14-rc2 instead of linux-next. > > > Ok thank you so much for your reply. > Now I am able to boot with v4.14-rc2. But now I am facing another > problem. > Now, I am not able to connect to internet from virtual box. > When I switch back to the default 4.10 the internet works normally. > I think the dlclient stopped working. > I am getting continuous logs related to apparmor like this: > apparmor="DENIED" comm=dhclient > apparmor="DENIED" comm=cups-browsed > > With 4.10, I tried installing apparmor-utils and then reboot with > 4.14-rc2, but it did not help. > Any suggestions on this? Hello, i resolved the issue with: sudo /etc/init.d/apparmor stop Damian > > > > > > - Ted _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
