Regarding the issues

1. MachAttributes::DevIdMatches will be not called if the tag does not exist.

2. It could be, if there is ever a reason to touch that code again I would change it, but it’s not worth changing all by itself.

3. I believe this is logging is useful for now, it’s more interesting than the other logging so having that log at D_ALWAYS is ok. This will log only on slot creation.

As a general point, it might be good to do an audit of the logging in the Startd and decide what things we really want to see at D_ALWAYS,

Code Review

This generally looks good. The comments were helpful (in part because some of the variable names were not, in part because the STL container API is a little clumsy); thanks.

I find it highly unlikely that the scheme used to represent multiple assigned resources in this patch really solves the problem of matchmaking with multiple resources. However, that is, strictly speaking, out of scope, so as long as the scheme remains undocumented, I’m OK with it; we have to have something, after all.

Minor issues:

• In MachAttributes::DevIdMatches(), why does the special case for indices not care if the resource tag doesn’t exist?

• Shouldn’t lines 967 and 971 of ResAttributes.cpp just be a single line before the conditional?

• Is line 1590 of ResAttributes.cpp debugging spam?

This can be tested by putting this in config, the multi-line form of SLOT_TYPE_n allows for a constraint expression, resource index or resource id string after an optional : on the line declaring the quantity of a custom resource.