> Not your motivations, just the posting mechanics. If you just want to > discuss a patch, and aren't yet proposing it for inclusion, you should > put RFC in the prefix of every patch header. I understand the principle, and I should have on those patches (mea culpa), but really *all* patch postings are for comment; I think of RFC as "comment only; please don't apply this". But it wasn't marked RFC, so that's why I posted a note downgrading it when I realized I messed it up. The note was basically "oh, shit, I introduced a bug at the last minute; thankfully that was the most RFC of the entire series, so nobody's likely to have merged it." But it certainly is the case that for any significant patch series, I really don't expect v1 to get merged as-is. I'm serious about the changes, and it wouldn't have been a problem if you had applied v1, but it would have surprised me. Realistically, I expect a couple of rounds of discussion and tweaking of the specific form of the changes before people agree it's ready to go in. And I think that's the case here; I adjusted a lot of details based on feedback, but at a high level nothing changed; v2 makes the same changes that v1 did. > Not particularly opposed to the idea, I just know that several use cases > rely on deterministic behavior for those entities that share the secret > information, so I need to be sure that the deterministic behavior remains > and is the default. Right, because it's advertised as a PRNG. Thinking about it, would a separate crypto_alg with a different seedsize be a better solution than obscure rules about seed size? And something in the cra_flags to indicate it's nondeterminsitic? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
