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/generic/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? > - Ted _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
