Paul Goyette wrote: > OK, I looked at all of the examples, except for the lua one (I am > lua-clueless). Everything looks OK to me, and I don't see any reason > not to commit these. >
Please try to follow the code, it should illuminate you. If it's too difficult it should be corrected. > I do, however, have a request... > > The "happy" module makes a claim that "4 digit numbers cannot cycle", > and uses a cache[] table for all numbers below 1000. Can you please > provide a reference to back up the "cannot cycle" claim? :) And please > initialize (or reinitialize) the entire cache[] array in your modcmd's > INIT routine, rather than a single static initialization. (It could > make a difference if the module were ever "built-in" to a kernel ...) > There are two algorithms: naive and optimal. The naive one uses caching and the optimal check whether we are in the cycle: 4, 16, 37, 58, 89, 145, 42, 20. The claims comes from this statement that the largest number from the cycle is 3-digit. I can go for the the optimal one and cut the caching design in the code. In the module example the algorithm implementation shouldn't divert attention from the important part - how to implement read(2). > Also, for all tests that create a cdevsw, please insert a comment to > ensure that the reader should verify that the number should be changed > if needed to avoid conflict with "real" devices. I will do it. > And maybe also note this in the README file? Good idea. > Definitely include a comment that these > modules should not be used on a "production" machine, just in case... > I will put a line about it in the README file. > Finally, I would appreciate it if other folks would weigh in on the > question of the directory hierarchy into which these examples should be > placed... > I like it. Maybe place them in `share/examples/kmodules'?
