by Boqun Feng

[permalink] [raw]

Same as the prior email, this was supposed to go to Daniel...

On 06/04/2023 14.02, Asahi Lina wrote:
> On 05/04/2023 23.44, Daniel Vetter wrote:
>> On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
>>> +/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
>>> +pub(crate) fn lookup_handle(file: &DrmFile, handle: u32) -> Result<ObjectRef> {
>>> + Ok(ObjectRef::new(shmem::Object::lookup_handle(file, handle)?))
>>> +}
>>
>> So maybe my expectations for rust typing is a bit too much, but I kinda
>> expected this to be fully generic:
>>
>> - trait Driver (drm_driver) knows the driver's object type
>> - a generic create_handle function could ensure that for drm_file (which
>> is always for a specific drm_device and hence Driver) can ensure at the
>> type level that you only put the right objects into the drm_file
>> - a generic lookup_handle function on the drm_file knows the Driver trait
>> and so can give you back the right type right away.
>>
>> Why the wrapping, what do I miss?
>
> Sigh, so this is one of the many ways I'm trying to work around the
> "Rust doesn't do subclasses" problem (so we can figure out what the best
> one is ^^).
>
> The generic shmem::Object::lookup_handle() call *is* fully generic and
> will get you back a driver-specific object. But since Rust doesn't do
> subclassing, what you get back isn't a driver-specific type T, but
> rather a (reference to a) shmem::Object<T>. T represents the inner
> driver-specific data/functionality (only), and the outer
> shmem::Object<T> includes the actual drm_gem_shmem_object plus a T. This
> is backwards from C, where you expect the opposite situation where T
> contains a shmem object, but that just doesn't work with Rust because
> there's no way to build a safe API around that model as far as I know.
>
> Now the problem is from the higher layers I want object operations that
> interact with the shmem::Object<T> (that is, they call generic GEM
> functions on the object). Options so far:
>
> 1. Add an outer wrapper and put that functionality there.
> 2. Just have the functions on T as helpers, so you need to call
> T::foo(obj) instead of obj.foo().
> 3. Use the undocumented method receiver trait thing to make
> shmem::Object<T> a valid `self` type, plus add auto-Deref to
> shmem::Object. Then obj.foo() works.
>
> #1 is what I use here. #2 is how the driver-specific File ioctl
> callbacks are implemented, and also sched::Job<T>. #3 is used for fence
> callbacks (FenceObject<T>). None of them are great, and I'd love to hear
> what people think of the various options...
>
> There are other unexplored options, like in this GEM case it could be
> covered with a driver-internal auxiliary trait impl'd on
> shmem::Object<T> buuut that doesn't work when you actually need
> callbacks on T itself to circle back to shmem::Object<T>, as is the case
> with File/Job/FenceObject.
>
> ~~ Lina
>

~~ Lina

2023-04-06 10:47:40

by Daniel Vetter

[permalink] [raw]

On Wed, Apr 05, 2023 at 09:29:02PM +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2023 at 05:43:01PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:37PM +0900, Asahi Lina wrote:
> > > +/// An armed DRM scheduler job (not yet submitted)
> > > +pub struct ArmedJob<'a, T: JobImpl>(Box<Job<T>>, PhantomData<&'a T>);
> > > +
> > > +impl<'a, T: JobImpl> ArmedJob<'a, T> {
> > > + /// Returns the job fences
> > > + pub fn fences(&self) -> JobFences<'_> {
> > > + JobFences(unsafe { &mut *self.0.job.s_fence })
> > > + }
> > > +
> > > + /// Push the job for execution into the scheduler
> > > + pub fn push(self) {
> > > + // After this point, the job is submitted and owned by the scheduler
> > > + let ptr = match self {
> > > + ArmedJob(job, _) => Box::<Job<T>>::into_raw(job),
> > > + };
> >
> > If I get this all right then this all makes sure that drivers can't use
> > the job after push and they don't forgot to call arm.
> >
> > What I'm not seeing is how we force drivers to call push once they've
> > called arm? I haven't check what the code does, but from the docs it
> > sounds like if you don't call push then drop will get called. Which wreaks
> > the book-keeping on an armed job. Or is there someting that prevents
> > ArmedJob<T> from having the Drop trait and so the only way to not go boom
> > is by pushing it?
> >
> > Googling for "rust undroppable" seems to indicate that this isn't a thing
> > rust can do?
>
> Another thing that I just realized: The driver must ensure that the
> arm->push sequence on a given drm_sched_entity isn't interrupte by another
> thread doing the same, i.e. you need to wrap it all in a lock, and it
> always needs to be the same lock for a given entity.
>
> I have no idea how to guarantee that, but I guess somehow we should?

Ok I was wrong here, pushing the job is optional, but the locking rules
are still the same.

I think we can solve this in rust with:
- passing &mut Entity to a new submit_job function. that way locking rules
are left to the driver, which I think is best.
- the submit_job also takes a closure, and passes the armed job as a &mut
ArmedJob to it. That way we guarantee that the armed job never survives
longer than the mutex guard (or whatever trick the driver is using) for
the Entity
- that closure probably should have Result return type which submit_job
just passes on, because some drivers (when you support userptr that is)
need to be able to bail out. since the ArmedJob is borred it shouldn't
be able to escape through the return value
- only ArmedJob has push_job

I think with that we fully uphold the drm_sched arm/push_job contract on
the rust side?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch