Re: [Xen-devel] [PATCH 4/9] dm_depriv: Describe expected usage of device_model_user parameter

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Nov 28, 2018, at 4:36 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> 
> George Dunlap writes ("[PATCH 4/9] dm_depriv: Describe expected usage of 
> device_model_user parameter"):
>> A number of subsequent patches rely on as-yet undefined behavior for
>> what the `device_model_user` parameter does.  Rather than implement it
>> incorrectly (or randomly), or remove the feature, describe an expected
>> usage for the feature.  Further patches will make decisions based on
>> this expected usage.
> 
> This document seems to document a fine feature.  I don't mind the docs
> patch being separate but I don't know why you wouldn't add it in the
> same patch as you implement it.

Because the feature is already implemented and working correctly according to 
the pre-series semantics (AFAICT), but not documented (other than a comment in 
libxl_types.idl saying, “is not ready for use yet” (which I suppose I should 
remove while I’m at it)).

When I came to implement kill-by-uid, I came upon the questions: If 
device_model_user is specified, should I attempt to kill by uid or not?  And, 
is device_model_user allowed to be “root”?

If we expect device_model_user not to be shared with any other domains, then we 
can (and probably should) kill by uid; and of course the uid must not be root.  
If we expect device_model_user to be shared with other domains, then we cannot 
kill by uid, and we might consider allowing the uid to be root.

I found no guidance in the code one way or the other; so this change is 
proposal of what I think is the most useful behavior: Namely, that we make the 
semantics “must be unique per domain”, rather than “may be shared”.

Given that...

> So, I guess,
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Does the Ack still stand?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel