From: Randy Dunlap <rdunlap@infradead.org>
To: Damian Tometzki <damian.tometzki@icloud.com>,
Pintu Kumar <pintu.ping@gmail.com>,
"Theodore Ts'o" <tytso@mit.edu>,
Valdis Kletnieks <valdis.kletnieks@vt.edu>,
linux-kernel@vger.kernel.org, kernelnewbies@kernelnewbies.org
Subject: Re: How to verify linux-next
Date: Sun, 1 Oct 2017 09:48:18 -0700 [thread overview]
Message-ID: <649f4bab-608d-9422-f2c3-401038c036c3@infradead.org> (raw)
In-Reply-To: <1506876289.2536.2.camel@icloud.com>
On 10/01/17 09:44, Damian Tometzki wrote:
>
> 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@mit.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/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
or boot with: apparmor=0
--
~Randy
next prev parent reply other threads:[~2017-10-01 16:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-29 9:42 How to verify linux-next Pintu Kumar
2017-09-29 9:46 ` Pintu Kumar
2017-09-29 10:38 ` Pintu Kumar
2017-09-29 12:41 ` valdis.kletnieks
2017-09-29 13:05 ` Damian Tometzki
2017-09-29 13:14 ` Damian Tometzki
2017-09-29 14:26 ` Pintu Kumar
2017-09-29 15:45 ` valdis.kletnieks
2017-10-02 8:11 ` Kamil Konieczny
2017-10-02 11:04 ` valdis.kletnieks
2017-09-29 17:53 ` Pintu Kumar
2017-09-29 21:50 ` Theodore Ts'o
2017-09-30 3:58 ` Pintu Kumar
2017-09-30 5:25 ` Theodore Ts'o
2017-10-01 16:28 ` Pintu Kumar
2017-10-01 16:44 ` Damian Tometzki
2017-10-01 16:48 ` Randy Dunlap [this message]
2017-10-01 17:03 ` Mike Galbraith
2017-10-01 18:47 ` Pintu Kumar
2017-10-01 16:47 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=649f4bab-608d-9422-f2c3-401038c036c3@infradead.org \
--to=rdunlap@infradead.org \
--cc=damian.tometzki@icloud.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pintu.ping@gmail.com \
--cc=tytso@mit.edu \
--cc=valdis.kletnieks@vt.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).