linux-kernel - Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zj5JIah0jWnIn2Ix@localhost.localdomain>
Date: Fri, 10 May 2024 18:19:45 +0200
From: Louis Chauvet <louis.chauvet@...tlin.com>
To: Jim Shargo <jshargo@...gle.com>
Cc: José Expósito <jose.exposito89@...il.com>,
	daniel@...ll.ch, brpol@...omium.org, corbet@....net,
	dri-devel@...ts.freedesktop.org, hamohammed.sa@...il.com,
	hirono@...omium.org, jshargo@...omium.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	mairacanal@...eup.net, marius.vlad@...labora.com,
	mduggan@...omium.org, melissa.srw@...il.com, mripard@...nel.org,
	rodrigosiqueiramelo@...il.com, tzimmermann@...e.de
Subject: Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!

Le 09/05/24 - 18:18, Jim Shargo a écrit :
> Sima--thanks SO MUCH for going through with everything leaving a
> detailed review. I am excited to go through your feedback.
> 
> It makes me extremely happy to see these patches get people excited.
> 
> They've bounced between a few people, and I recently asked to take
> them over again from the folks who were most recently looking at them
> but haven't since had capacity to revisit them. I'd love to contribute
> more but I am currently pretty swamped and I probably couldn't
> realistically make too much headway before the middle of June.
> 
> José--if you've got capacity and interest, I'd love to see this work
> get in! Thanks!! Please let me know your timeline and if you want to
> split anything up or have any questions, I'd love to help if possible.
> But most important to me is seeing the community benefit from the
> feature.
> 
> And (in case it got lost in the shuffle of all these patches) the IGT
> tests really make it much easier to develop this thing. Marius has
> posted the most recent patches:
> https://lore.kernel.org/igt-dev/?q=configfs
> 
> Thanks!
> -- Jim
> 
> 
> 
> On Wed, May 8, 2024 at 2:17 PM José Expósito <jose.exposito89@...il.com> wrote:
> >
> > Hi everyone,
> >
> > I wasn't aware of these patches, but I'm really glad they are getting
> > some attention, thanks a lot for your review Sima.
> >
> > Given that it's been a while since the patches were emailed, I'm not
> > sure if the original authors of the patches could implement your
> > comments. If not, I can work on it. Please let me know.
> >
> > I'm working on a Mutter feature that'd greatly benefit from this uapi
> > and I'm sure other compositors would find it useful.
> >
> > I'll start working on a new version in a few days if nobody else is
> > already working on it.
> >
> > Best wishes,
> > José Expósito

Hi all!

Very nice to see other people working on this subject. As the series 
seemed inactive, I started two weeks ago to rebase it on top of [1]. I 
also started some work to use drmm_* helpers instead of using lists in 
vkms. I currently struggle with a deadlock during rmmod.

I need to clean my commits, but I can share a WIP version.

Maybe we can discuss a bit the comment from Daniel (split init between 
default/configfs, use or not a real platform device...)

For the split, I think the first solution (struct vkms_config) can be 
easier to understand and to implement, for two reasons:
- No need to distinguish between the "default" and the "configfs" devices 
  in the VKMS "core". All is managed with only one struct vkms_config.
- Most of the lifetime issue should be gone. The only thing to 
  synchronize is passing this vkms_config from ConfigFS to VKMS.

The drawback of this is that it can become difficult to do the "runtime" 
configuration (today only hotplug, but I plan to add more complex stuff 
like DP emulation, EDID selection, MST support...). Those configuration 
must be done "at runtime" and will require a strong synchronization with 
the vkms "core".

Maybe we can distinguish between the "creation" and the "runtime 
configuration", in two different configFS directory? Once a device is 
created, it is moved to the "enabled" directory and will have a different 
set of attribute (connection status, current EDID...)

For the platform driver part, it seems logic to me to use a "real" 
platform driver and a platform device for each pipeline, but I don't have 
the experience to tell if this is a good idea or not.

[1]: https://lore.kernel.org/dri-devel/20240409-yuv-v6-0-de1c5728fd70@bootlin.com/

Thanks,
Louis Chauvet

-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com