linux-kernel - Re: [PATCH RFC v2 00/16] drm/vkms: ConfigFS interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241126-overjoyed-knowing-cuttlefish-c8d0f6@houat>
Date: Tue, 26 Nov 2024 09:42:02 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>, 
	Melissa Wen <melissa.srw@...il.com>, Maíra Canal <mairacanal@...eup.net>, 
	Haneen Mohammed <hamohammed.sa@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Simona Vetter <simona.vetter@...ll.ch>, 
	jose.exposito89@...il.com, dri-devel@...ts.freedesktop.org, arthurgrillo@...eup.net, 
	linux-kernel@...r.kernel.org, jeremie.dautheribes@...tlin.com, miquel.raynal@...tlin.com, 
	thomas.petazzoni@...tlin.com, seanpaul@...gle.com, nicolejadeyee@...gle.com
Subject: Re: [PATCH RFC v2 00/16] drm/vkms: ConfigFS interface

Hi,

On Fri, Nov 22, 2024 at 06:44:18PM +0100, Louis Chauvet wrote:
> On 22/11/24 - 18:38, Louis Chauvet wrote:
> > VKMS is manly used to test userspace program and its behavior. The current 
> > implementation is not very configurable as you can only have one device, 
> > with few specific planes.
> > 
> > This series aims to introduce a new interface, using ConfigFS, to create 
> > and configure more devices. This will introduce:
> > - Device creation
> > - Plane creation
> > - Plane configuration (type, color encoding, color range, rotations)
> > - Encoder creation
> > - CRTC creation
> > - Linking between CRTC and planes/encoders
> > 
> > The proposition is:
> > /config/vkms
> > 	DEVICE_1
> > 	┣━ enable
> > 	┣━ writeback
> > 	┣━ planes
> > 	┃  ┣━ PLANE_1
> > 	┃  ┃  ┣━ type
> > 	┃  ┃  ┣━ supported_rotations
> > 	┃  ┃  ┣━ color_range
> > 	┃  ┃  ┣━ color_encoding
> > 	┃  ┃  ┣━ default_color_encoding
> > 	┃  ┃  ┣━ default_rotations
> > 	┃  ┃  ┣━ default_color_range
> > 	┃  ┃  ┗━ possible_crtcs
> > 	┃  ┃     ┗━ >> /config/vkms/DEVICE_1/crtc/CRTC_1 
> > 	┃  ┣━ PLANE_2
> > 	┃  ┃  ┗━ ditto
> > 	┃  ┗━ PLANE_3
> > 	┃     ┗━ ditto
> > 	┃
> > 	┣━ encoders
> > 	┃  ┣━ ENCODER_1
> > 	┃  ┃  ┗━ possible_crtcs
> > 	┃  ┃     ┗━ >> /config/vkms/DEVICE_1/crtc/CRTC_1
> > 	┃  ┗━ ENCODER_2
> > 	┃     ┗━ ditto
> > 	┃
> > 	┗━ crtc
> > 	   ┗━ CRTC_1
> > 	
> > This interface aims to be extendable (new property can easly be added in 
> > objects) and easy to use (objects are created simply by creating folders, 
> > and configured by writing files).
> > 
> > This series depends on 
> > https://lore.kernel.org/all/20241122-google-remove-crtc-index-from-parameter-v2-0-81540742535a@bootlin.com
> > but as this is a bit complex to rebase, you can find a working branch 
> > here:
> > https://gitlab.freedesktop.org/louischauvet/kernel/-/tree/b4/vkms-configfs
> > 
> > Signed-off-by: Louis Chauvet <louis.chauvet@...tlin.com>
> 
> Hi all,
> 
> I am also currently working on MST emulation for VKMS. If someone can read 
> what I already did and at tell me if my implementation seems on the right 
> track it could be nice.
> 
> The current status is not very advanced: I can emulate a mst HUB, but not 
> a screen. I am currently working on properly emulating the HUB by using an 
> other hub.
> 
> You can find the branch for this work here:
> https://gitlab.freedesktop.org/louischauvet/kernel/-/tree/b4/vkms-mst

I think this is exactly the kind of things where we'll want eBPF I
think. There's no way you'll be able to model each possible test
scenarios for MST through configfs, even more so with a stable
interface.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)