Re: (patch) Improved documentation and examples of dynamic modules

["Kamil Rytarowski" <n54%gmx.com@localhost>]

Greg Troxel wrote:
> "Kamil Rytarowski" <n54%gmx.com@localhost> writes:
> 

Thank you Greg for your reply!

> > Paul Goyette wrote:
> >> 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).
> 
> My reaction to this is that this entire algorithm is a distraction to
> the module example.
> 

It will be simplified.

> Also, "happy" doesn't seem like a useful name; examples should have
> names that suggest the kinds of things they do with respect to the
> module system, to guide people choosing which ones to read.
> 

Well, I like /dev/happy for Happy Number generator. What would be the
better name?

> > I like it. Maybe place them in `share/examples/kmodules'?
> 
> share/examples/sys/modules would be better; kmodules is not the name of
> a program in base and would be confusing to someone expecting examples
> to be about programs in base.
> 

kmodule was inspired by (/usr/share/mk/)bsd.kmodule.mk and it was so
natural for me to pick up this name. Maybe share/examples/sys/kmodule?

> There's already an example module in the kernel source tree, too.  I
> don't follow why that just can't be improved.
> 
I'm improving this single example adding to it 4 additional modules and
README. There is no revolution, except moving the original example to a
new location.

The approach 'Ab uno disces omnis' (from one [example] learn everything)
was insufficient for me and I had to do research, now I'm going to make
this knowledge available for everybody.

I'm trying to improve the documentation and add more enlightening examples
for newcomers (like myself!).

I'm aware of the fact that experienced kernel programmers familiar with
NetBSD internals know how to handle all kinds of things, dependencies and
for them following 'ab uno disces omnis' (single example just parsing the
parameters) is sufficient.

Please let it be easier for people starting to hack in the kernel from
the modules (people like me) and not assuming they mastered the kernel
internals.