On 3/31/20 12:22 PM, Michael S. Tsirkin wrote:> On Tue, Mar 31, 2020 at 11:42:47AM -0700, Randy Dunlap wrote:
>> On 3/31/20 11:37 AM, Michael S. Tsirkin wrote:
>>> On Tue, Mar 31, 2020 at 11:27:54AM -0700, Randy Dunlap wrote:
>>>> On 3/30/20 6:47 PM, akpm at linux-foundation.org wrote:
>>>>> The mm-of-the-moment snapshot 2020-03-30-18-46 has been
uploaded to
>>>>>
>>>>> http://www.ozlabs.org/~akpm/mmotm/
>>>>>
>>>>> mmotm-readme.txt says
>>>>>
>>>>> README for mm-of-the-moment:
>>>>>
>>>>> http://www.ozlabs.org/~akpm/mmotm/
>>>>>
>>>>> This is a snapshot of my -mm patch queue. Uploaded at
random hopefully
>>>>> more than once a week.
>>>>>
>>>>> You will need quilt to apply these patches to the latest
Linus release (5.x
>>>>> or 5.x-rcY). The series file is in broken-out.tar.gz and
is duplicated in
>>>>> http://ozlabs.org/~akpm/mmotm/series
>>>>>
>>>>> The file broken-out.tar.gz contains two datestamp files:
.DATE and
>>>>> .DATE-yyyy-mm-dd-hh-mm-ss. Both contain the string
yyyy-mm-dd-hh-mm-ss,
>>>>> followed by the base kernel version against which this
patch series is to
>>>>> be applied.
>>>>>
>>>>> This tree is partially included in linux-next. To see
which patches are
>>>>> included in linux-next, consult the `series' file.
Only the patches
>>>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers
are included in
>>>>> linux-next.
>>>>>
>>>>>
>>>>> A full copy of the full kernel tree with the linux-next and
mmotm patches
>>>>> already applied is available through git within an hour of
the mmotm
>>>>> release. Individual mmotm releases are tagged. The master
branch always
>>>>> points to the latest release, so it's constantly
rebasing.
>>>>>
>>>>> https://github.com/hnaz/linux-mm
>>>>
>>>> on i386:
>>>>
>>>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_init':
>>>> vdpa.c:(.init.text+0x52): undefined reference to
`__vdpa_register_driver'
>>>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_exit':
>>>> vdpa.c:(.exit.text+0x14): undefined reference to
`vdpa_unregister_driver'
>>>>
>>>>
>>>>
>>>> drivers/virtio/vdpa/ is not being built. (confusing!)
>>>>
>>>> CONFIG_VIRTIO=m
>>>> # CONFIG_VIRTIO_MENU is not set
>>>> CONFIG_VDPA=y
>>>
>>> Hmm. OK. Can't figure it out. CONFIG_VDPA is set why isn't
>>> drivers/virtio/vdpa/ built?
>>> we have:
>>>
>>
>> Ack. Hopefully Yamada-san can tell us what is happening here.
>
> OK I pushed a fix (moving the vdpa subsystem up a level) and pushed into
> my tree, refs/heads/next . Seems to build fine now, but I'd appreciate
> it if you can give it a spin.
This now builds successfully on linux-next of 20200401.
Thanks.
--
~Randy