[Cryptography] RFC possible changes for Linux random device

[Jason Cooper]

On Sat, Sep 13, 2014 at 03:32:15PM -0400, Sandy Harris wrote:
> On Sat, Sep 13, 2014 at 3:08 PM, Jason Cooper
> <cryptography at lakedaemon.net> wrote:
> 
> > + Ted Ts'o, H. Peter Anvin
> >
> > On Fri, Sep 12, 2014 at 07:18:58PM -0400, Sandy Harris wrote:
> 
> >> I have some experimental code to replace parts of random.c ...
> 
> > Here's my recommendation:  Follow the instructions below to generate a
> > patch against the current, mainline kernel tree.  Then post the patch to
> > lkml with Ted Ts'o, and H. Peter Anvin on the Cc.
> >
> > We need to see a diff against the mainline tree because it allows us to
> > more easily review your idea(s).
> 
> I do want to do that eventually. Thanks for the pointers to instructions.
> 
> However, the code is not complete; there are a bunch of comments
> suggesting where things could be added, but those parts are not
> yet written. Also, I'd like to have it reviewed by the cryptography
> list (where most of the ideas in it have previously been discussed)
> before proposing it for the kernel.

Right, I'm a big advocate of involving everyone early in the process.
Adding 'RFC' to the patch submission (which I forgot to mention) lets
kernel folks know that the code isn't ready for inclusion.

There's no reason you couldn't cross-post to both lists.  Ted Ts'o
previously asked if conversations regarding implementations (patches,
etc) were welcome on the cryptography list and he received no
objections.

> Also, it would be a large patch. My program is over 1500 lines,
> though at least half of those are comments or scaffolding for
> testing it. Add the missing bits and some changes to current
> code to integrate it and it would be a 1000+ line patch. I am
> not sure whether or how that should be split up.

I've seen bigger :)  As long as each patch contains one logical change,
and the code still builds after each patch, we'll figure out a way to
handle it.

> > A fair head's up:  You're going to get a lot of warnings on comment
> > style.  Single-line comments are '/* ... */' and multi-line are:
> >
> >         /*
> >          * something
> >          * about the code goes here
> >          */
> >
> > Yes, there are many ways to do it, but I always try to conform to the
> > style of a given project so it's consistent within that tree.
> 
> I started off modifying random.c and deliberately chose a different
> comment style so my comments could be distinguished from the
> ones already in the file. I will fix this before I send patches.

I would highly suggest trying out the git workflow I posted.  Using 'git
diff' alone will show you exactly what you've changed and then you'll
have less work to do later.  I know workflows are highly-specific to
the developer, so whatever works for you is fine.

thx,

Jason.