Message ID | 20190911125122.20772-1-johannes@sipsolutions.net |
---|---|
Headers | show |
Series | um: virtio support | expand |
On Wed, 2019-09-11 at 14:51 +0200, Johannes Berg wrote: > Yet another respin, with a small fix in the virtio platform data > freeing code. I'm getting to the "tiny little fixes" territory, so would appreciate if you could give it a spin again. I think quite possibly much of the issues you saw were just from the uninitialized variable we had in one of the early versions, and regardless of that the error messages should be more verbose now. johannes
On 11/09/2019 14:18, Johannes Berg wrote: > On Wed, 2019-09-11 at 14:51 +0200, Johannes Berg wrote: >> Yet another respin, with a small fix in the virtio platform data >> freeing code. > > I'm getting to the "tiny little fixes" territory, so would appreciate if > you could give it a spin again. > > I think quite possibly much of the issues you saw were just from the > uninitialized variable we had in one of the early versions, and > regardless of that the error messages should be more verbose now. > > johannes > > > _______________________________________________ > linux-um mailing list > linux-um@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-um > I will try to find it a timeslot later today or failing that tomorrow morning. Brhds
On 11/09/2019 14:33, Anton Ivanov wrote: > > > On 11/09/2019 14:18, Johannes Berg wrote: >> On Wed, 2019-09-11 at 14:51 +0200, Johannes Berg wrote: >>> Yet another respin, with a small fix in the virtio platform data >>> freeing code. >> >> I'm getting to the "tiny little fixes" territory, so would appreciate if >> you could give it a spin again. >> >> I think quite possibly much of the issues you saw were just from the >> uninitialized variable we had in one of the early versions, and >> regardless of that the error messages should be more verbose now. >> >> johannes >> >> >> _______________________________________________ >> linux-um mailing list >> linux-um@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-um >> > > > I will try to find it a timeslot later today or failing that tomorrow > morning. It does not build as is at the moment, you need to add EXPORT_SYMBOL(uml_reserved); to ./kernel/um_arch.c I could not find that anywhere in the patch series so it is probably lingering in your tree from somewhere else. It will be a good idea to respin everything including the patches it depends vs current 5.x head so that we have a "definitive test with this" version to work with. Brgds,
On Fri, 2019-09-13 at 09:14 +0100, Anton Ivanov wrote: > It does not build as is at the moment, you need to add > > EXPORT_SYMBOL(uml_reserved); > > to ./kernel/um_arch.c > > I could not find that anywhere in the patch series so it is probably > lingering in your tree from somewhere else. Oh, no, but I've been using it built-in rather than as a module, sorry. > It will be a good idea to respin everything including the patches it > depends vs current 5.x head so that we have a "definitive test with > this" version to work with. I guess I'll have to test build it a bit more in various configs :) johannes
On Fri, Sep 13, 2019 at 10:16 AM Johannes Berg <johannes@sipsolutions.net> wrote: > > On Fri, 2019-09-13 at 09:14 +0100, Anton Ivanov wrote: > > > It does not build as is at the moment, you need to add > > > > EXPORT_SYMBOL(uml_reserved); > > > > to ./kernel/um_arch.c > > > > I could not find that anywhere in the patch series so it is probably > > lingering in your tree from somewhere else. > > Oh, no, but I've been using it built-in rather than as a module, sorry. This can be fixed after -rc1.