[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOuPNLj0v1GqCzs_twO8rLREBh0yXq22LbJrxri-eFmbjehEmg@mail.gmail.com>
Date: Sun, 1 Oct 2017 21:58:37 +0530
From: Pintu Kumar <pintu.ping@...il.com>
To: "Theodore Ts'o" <tytso@....edu>,
Pintu Kumar <pintu.ping@...il.com>,
Damian Tometzki <damian.tometzki@...oud.com>,
Valdis Kletnieks <valdis.kletnieks@...edu>,
linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org
Subject: Re: How to verify linux-next
On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o <tytso@....edu> 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
Powered by blists - more mailing lists