All pushed. Thanks for contributing a Rust implementation!

> If it is not the intention to license this under CC-BY-SA 4.0 and to use
> an earlier version instead, please fix this up, but I feel that a link
> to the license should be provided.

Yes, CC-BY-SA 4.0 is the intention. Slightly edited your commit to make
this even clearer by including the version in the link text.

There is also a LICENSE file containing the full license text, but I
guess it doesn't hurt to provide a link as well.

Both Caddy and POSIX sh just allow quoted strings to span over multiple
lines, so I was considering not adding any new syntax and simply remove
the restriction that quoted strings must be single-line. What do you
think?

Nice, thanks for creating this project!

Pushed:

To git.sr.ht:~emersion/scfg
   88e5dfb344e1..279e78b70152  master -> master

Pushed, thanks!

On Tuesday, September 15, 2020 7:35 AM, James Jones <jajones@nvidia.com> wrote:
> > I've tried collecting a list of potential use-cases that'll involve buffer
> > constraints:
> >
> > - Use optimal layout when the buffer won't be used for scan-out (right now
> >    drivers have to assume buffers with a scanout-capable modifier will be used
> >    for scan-out).
> > - Share buffers between the render and display engines on the same SoC, share
> >    buffers between two GPUs from the same vendor.
> > - Share buffers between two GPUs from different vendors.
> >
> > And then tried to figure out how they'd work with our WIP proposal. I've likely
> > got some things wrong, let me know if that's the case.
> >

datetime.replace discards the previous timezone. Instead, convert to UTC.

This fixes ordering of messages in a thread when each has a different
timezone.
---
 listssrht/process.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/listssrht/process.py b/listssrht/process.py
index 9bea37eba4d9..6ad9bacc5fdf 100644
--- a/listssrht/process.py
+++ b/listssrht/process.py
@@ -20,7 +20,7 @@ import re
 import smtplib
[message trimmed]

I just noticed this TODO in the notes:

> TODO: Look up how dma-buf heaps are identified in kernel right now.
> Do they each have a device node with a minor number?  An ID within
> the dma-buf heap API.  Need to do some minimal source code
> inspection/research

Heaps IDs are identified by a plain-text name (see dma_heap_add in
include/linux/dma-heap.h). Anonymous heaps don't exist, and heaps don't
have an ID.

We'll probably want to change this. A device may want to grab a heap ID
to be able to express local constraints, but it's probably undesirable
to expose the heap on the filesystem.

> >> -Each constraint still contains a version in its "header" field, along
> >> with type and size
> >
> > I don't know if an explicit "version" field is absolutely required. Maybe
> > having just a #define DRM_CONSTRAINT_FOO_VERSION would be enough.
>
> Yes I suppose this is an option.  Unless I'm missing something though,
> this requires building a (constraint type, version) table at compile
> time in anything that wants to extract a version from a constraint.
> Maybe that's not a big deal, but it can be a lot of data if constraints
> proliferate.  Tradeoff of static data Vs. data on the wire I suppose.

The merging library and the allocator need to support all constraints anyways,
and the version is just an int per constraint, so I don't think this adds a

LGTM, pushed. Thanks!

> On 9/10/20 11:03 AM, Simon Ser wrote:
> > Here are more thoughts about versioning, sorry for the brain dump.
> >
> > * * *
> >
> > Let's say constraints v2 introduce heap constraints.
> >
> > - v1: producer assumes heap=vidmem
> > - v2: allocator only uses vidmem if constrained to
> > - v2: producer needs to add an explicit heap=vidmem constraint
> >
> > Need to negotiate version with everybody involved beforehand, which is
> > annoying. The constraint producers/consumers could change over time, which
> > makes things more complicated.