Received-SPF: pass (google.com: domain of linux-kernel+bounces-177323-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 13 May 2024 10:08:38 +0200
From: =?iso-8859-1?Q?Jos=E9_Exp=F3sito?= <jose.exposito89@gmail.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Jim Shargo <jshargo@google.com>, daniel@ffwll.ch, brpol@chromium.org,
	corbet@lwn.net, dri-devel@lists.freedesktop.org,
	hamohammed.sa@gmail.com, hirono@chromium.org, jshargo@chromium.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	mairacanal@riseup.net, marius.vlad@collabora.com,
	mduggan@chromium.org, melissa.srw@gmail.com, mripard@kernel.org,
	rodrigosiqueiramelo@gmail.com, tzimmermann@suse.de
Subject: Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
Message-ID: <ZkHKhtBmyS12i3fH@fedora>
References: <ZjCtgSaL50YrS-F-@phenom.ffwll.local>
 <20240508181744.7030-1-jose.exposito89@gmail.com>
 <CACmi3jF6Dp3PE8X=T5kTO2+eYJQi7jWACFdmp9jzKxUtcQphnQ@mail.gmail.com>
 <Zj5JIah0jWnIn2Ix@localhost.localdomain>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Zj5JIah0jWnIn2Ix@localhost.localdomain>

On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote:
> 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@gmail.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.

Hi Louis,

If you could share a RFC/WIP series it would be awesome!

Since you are already working on the kernel patches (and I guess IGT?),
I'll start working on a libdrm high level API to interact with VKMS from
user-space on top of your patches. I'll share a link as soon as I have a
draft PR.

> 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.

I agree, this seems like the easiest solution.

> 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...)

Once the device is enabled (i.e, `echo 1 > /config/vkms/my-device/enabled`),
would it make sense to use sysfs instead of another configfs directory?
The advantage is that with sysfs the kernel controls the lifetime of the
objects and I think it *might* simplify the code, but I'll need to write a
proof of concept to see if this works.

> 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.

I'm afraid I don't know which approach could work better. Trusting Sima and
Maíra on this one.

Jose

> [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