On 13.12.23 23:01, John Hubbard wrote:
On 12/13/23 01:59, David Hildenbrand wrote:
...
Another variation though, would be to run "make headers", and snapshot
some of those files into tools/include.
^ this is what I had in mind
If you're writing a test that needs some new fancy thing, update t
On 12/13/23 01:59, David Hildenbrand wrote:
...
Another variation though, would be to run "make headers", and snapshot
some of those files into tools/include.
^ this is what I had in mind
If you're writing a test that needs some new fancy thing, update the relevant
header.
OK, and Mark Bro
On Wed, Dec 13, 2023 at 08:58:06AM +0500, Muhammad Usama Anjum wrote:
> On 12/13/23 7:14 AM, John Hubbard wrote:
> > Oh, this sounds like it would work nicely. No more "make headers"
> > required (hooray!). Instead, the new approach would be "selftests are
> > allowed to include from tools/include
On 13.12.23 06:55, John Hubbard wrote:
On 12/12/23 21:52, John Hubbard wrote:
On 12/12/23 19:58, Muhammad Usama Anjum wrote:
...
Oh, this sounds like it would work nicely. No more "make headers"
required (hooray!). Instead, the new approach would be "selftests are
allowed to include from tools/
On 12/12/23 21:52, John Hubbard wrote:
On 12/12/23 19:58, Muhammad Usama Anjum wrote:
...
Oh, this sounds like it would work nicely. No more "make headers"
required (hooray!). Instead, the new approach would be "selftests are
allowed to include from tools/include", and then we can just start
cop
On 12/12/23 19:58, Muhammad Usama Anjum wrote:
...
Oh, this sounds like it would work nicely. No more "make headers"
required (hooray!). Instead, the new approach would be "selftests are
allowed to include from tools/include", and then we can just start
copying the files that we need to that loca
On 12/13/23 7:14 AM, John Hubbard wrote:
> On 12/12/23 07:12, Mark Brown wrote:
>> On Mon, Dec 11, 2023 at 12:29:58PM -0800, John Hubbard wrote:
>>> On 12/11/23 12:21, Mark Brown wrote:
> ...
>>> Or maybe there is an innovative way to do all of this, that we have
>>> yet to think of.
>>
>> We do co
On 12/12/23 07:12, Mark Brown wrote:
On Mon, Dec 11, 2023 at 12:29:58PM -0800, John Hubbard wrote:
On 12/11/23 12:21, Mark Brown wrote:
...
Or maybe there is an innovative way to do all of this, that we have
yet to think of.
We do copy files into tools/include at random times which makes sen
On Tue, Dec 12, 2023 at 04:27:12PM +0100, David Hildenbrand wrote:
> I usually build my stuff in-tree, so I don't really have a lot of experience
> with out-of-tree selftest builds and the whole kernel header inclusion (and
> how we could avoid the "make headers" and place the headers somewhere el
On 11.12.23 21:11, John Hubbard wrote:
On 12/11/23 12:01, Mark Brown wrote:
On Mon, Dec 11, 2023 at 07:00:32PM +0100, David Hildenbrand wrote:
On 11.12.23 18:32, Mark Brown wrote:
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
https://lkml.kernel.org/r/20231209020144.244
On Mon, Dec 11, 2023 at 12:29:58PM -0800, John Hubbard wrote:
> On 12/11/23 12:21, Mark Brown wrote:
> > additional variables that depend on the user's build environment, we
> > already have enough build issues. It ought to be mostly tedious rather
> > than hard but it's still a pain, especially
On 12/11/23 12:21, Mark Brown wrote:
On Mon, Dec 11, 2023 at 10:46:23AM -0800, John Hubbard wrote:
Or (4) Hack in little ifdef snippets, into the selftests, like we used
to do. Peter Zijlstra seems to be asking for this, if I understand his
(much) earlier comments about this.
I can't help but
On Mon, Dec 11, 2023 at 10:46:23AM -0800, John Hubbard wrote:
> Or (4) Hack in little ifdef snippets, into the selftests, like we used
> to do. Peter Zijlstra seems to be asking for this, if I understand his
> (much) earlier comments about this.
I can't help but think that if we're having to manu
On 12/11/23 12:01, Mark Brown wrote:
On Mon, Dec 11, 2023 at 07:00:32PM +0100, David Hildenbrand wrote:
On 11.12.23 18:32, Mark Brown wrote:
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
https://lkml.kernel.org/r/20231209020144.244759-1-jhubb...@nvidia.com
I mean, I g
On Mon, Dec 11, 2023 at 07:00:32PM +0100, David Hildenbrand wrote:
> On 11.12.23 18:32, Mark Brown wrote:
> > On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
> > > https://lkml.kernel.org/r/20231209020144.244759-1-jhubb...@nvidia.com
> > I mean, I guess people who don't want to
On 12/11/23 08:32, David Hildenbrand wrote:
...
That's an open question: do we want to be able to build selftests
against any host headers, and not the in-tree headers that have to be
manually installed and dirty the git tree?
One obvious drawbacks is that we'll have to deal with all that usin
On 11.12.23 18:32, Mark Brown wrote:
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
(3) avoids dirtying the tree as a "make headers_install" would, but it also
means that each test that makes use of new uapi has to update the relevant
headers (what people working on QEMU are
On Mon, Dec 11, 2023 at 05:53:59PM +0100, David Hildenbrand wrote:
> > > (3) avoids dirtying the tree as a "make headers_install" would, but it
> > > also
> > > means that each test that makes use of new uapi has to update the relevant
> > > headers (what people working on QEMU are used to).
> >
Further, the tests are closely related to the given kernel version, they are
not some completely separate tests.
Note that there's a general desire for the tests to *run* with older
kernels and use whatever feature test mechanisms exist to skip tests
that won't run. That's often needed anyway f
On Mon, Dec 11, 2023 at 8:34 AM Mark Brown wrote:
>
> On Mon, Dec 11, 2023 at 08:29:06AM -0800, Suren Baghdasaryan wrote:
>
> > Just to rule out this possibility, linux-next was broken on Friday
> > (see
> > https://lore.kernel.org/all/cajucfpfieqro4qkfzbucmgzy-n_ucqgr5neyvnwxqyh+ru4...@mail.gmai
On Mon, Dec 11, 2023 at 05:32:16PM +0100, David Hildenbrand wrote:
> On 11.12.23 17:15, Suren Baghdasaryan wrote:
> > Ok, I was updating my headers and that's why I could not reproduce it.
> > David, should the test be modified to handle old linux headers
> > (disable the new tests #ifndef _UFFDIO
On Mon, Dec 11, 2023 at 08:29:06AM -0800, Suren Baghdasaryan wrote:
> Just to rule out this possibility, linux-next was broken on Friday
> (see
> https://lore.kernel.org/all/cajucfpfieqro4qkfzbucmgzy-n_ucqgr5neyvnwxqyh+ru4...@mail.gmail.com/).
> I just checked and it's fixed now. Could you confir
On 11.12.23 17:15, Suren Baghdasaryan wrote:
On Mon, Dec 11, 2023 at 4:24 AM Mark Brown wrote:
On Mon, Dec 11, 2023 at 01:03:27PM +0100, David Hildenbrand wrote:
On 11.12.23 12:15, Mark Brown wrote:
This is linux-next. I pasted the commands used to build and sent links
to a full build log
On Mon, Dec 11, 2023 at 8:25 AM Mark Brown wrote:
>
> On Mon, Dec 11, 2023 at 08:15:11AM -0800, Suren Baghdasaryan wrote:
> > On Mon, Dec 11, 2023 at 4:24 AM Mark Brown wrote:
>
> > > Oh, it's obviously the new headers not being installed. The builds
> > > where I'm seeing the problem (my own an
On Mon, Dec 11, 2023 at 08:15:11AM -0800, Suren Baghdasaryan wrote:
> On Mon, Dec 11, 2023 at 4:24 AM Mark Brown wrote:
> > Oh, it's obviously the new headers not being installed. The builds
> > where I'm seeing the problem (my own and KernelCI's) are all fresh
> > containers so there shouldn't
On Mon, Dec 11, 2023 at 4:24 AM Mark Brown wrote:
>
> On Mon, Dec 11, 2023 at 01:03:27PM +0100, David Hildenbrand wrote:
> > On 11.12.23 12:15, Mark Brown wrote:
>
> > > This is linux-next. I pasted the commands used to build and sent links
> > > to a full build log in the original report.
>
> >
On Mon, Dec 11, 2023 at 01:03:27PM +0100, David Hildenbrand wrote:
> On 11.12.23 12:15, Mark Brown wrote:
> > This is linux-next. I pasted the commands used to build and sent links
> > to a full build log in the original report.
> Probably also related to "make headers-install":
> https://lkml.
On 11.12.23 12:15, Mark Brown wrote:
On Sun, Dec 10, 2023 at 07:04:19PM -0800, Suren Baghdasaryan wrote:
On Sun, Dec 10, 2023 at 5:01 PM Suren Baghdasaryan wrote:
Thanks for reporting! I'll try that later today.
Just to clarify, are you using mm-unstable and if so, has it been
rebased since
On Sun, Dec 10, 2023 at 07:04:19PM -0800, Suren Baghdasaryan wrote:
> On Sun, Dec 10, 2023 at 5:01 PM Suren Baghdasaryan wrote:
> > Thanks for reporting! I'll try that later today.
> > Just to clarify, are you using mm-unstable and if so, has it been
> > rebased since Friday? There was an update
On Sun, Dec 10, 2023 at 5:01 PM Suren Baghdasaryan wrote:
>
> On Sun, Dec 10, 2023 at 6:26 AM Mark Brown wrote:
> >
> > On Wed, Dec 06, 2023 at 02:36:59AM -0800, Suren Baghdasaryan wrote:
> > > Add tests for new UFFDIO_MOVE ioctl which uses uffd to move source
> > > into destination buffer while
On Sun, Dec 10, 2023 at 6:26 AM Mark Brown wrote:
>
> On Wed, Dec 06, 2023 at 02:36:59AM -0800, Suren Baghdasaryan wrote:
> > Add tests for new UFFDIO_MOVE ioctl which uses uffd to move source
> > into destination buffer while checking the contents of both after
> > the move. After the operation t
On Wed, Dec 06, 2023 at 02:36:59AM -0800, Suren Baghdasaryan wrote:
> Add tests for new UFFDIO_MOVE ioctl which uses uffd to move source
> into destination buffer while checking the contents of both after
> the move. After the operation the content of the destination buffer
> should match the origi
32 matches
Mail list logo
