On 8/31/21 2:35 PM, Daniel Vetter wrote:
On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
[snip]
We talked about a drmcon with Peter Robinson as well but then decided that a way to disable CONFIG_FB but still having the DRM fbdev emulation could be a intermediary step, hence these RFC patches.
But yes, I agree that a drmcon would be the proper approach for this, to not need any fbdev support at all. We will just keep the explicit disable for the fbdev drivers then in the meantime.
I think the only intermediate step would be to disable the fbdev uapi (char node and anything in sysfs), while still registering against the fbcon layer so you have a console.
Right, $subject disabled the sysfs interface but left the fbdev chardev. I can try to do a v2 that also disables that interface but just keep the fbcon part.
But looking at the things syzbot finds the really problematic code is all in the fbcon and console layer in general, and /dev/fb0 seems pretty solid.
Yes, but still would be an improvement in the sense that no legacy fbdev uAPI will be exposed and so user-space would only depend on the DRM/KMS interface.
I think for a substantial improvement here in robustness what you really want is
- kmscon in userspace
- disable FB layer
- ideally also disable console/vt layer in the kernel
Earlier in the thread it was mentioned that an in-kernel drmcon could be used instead. My worry with kmscon is that moving something as critical as console output to user-space might make harder to troubleshoot early booting issues.
And also that will require user-space changes. An in-kernel drmcon could be a drop-in replacement though.
- have a minimal emergency/boot-up log thing in drm, patches for that floated around a few times
Interesting. Do you have any pointers for this? My search-fu failed me when trying to find these patches.
Best regards,