Re: kernel config
Marty Leisner (leisner@sdsp.mc.xerox.com)
Wed, 26 Jul 1995 09:44:32 PDT
>
> On Fri, 21 Jul 1995, Roland Dunkerley wrote:
>
> > Proper documentation would be nice. Man pages for kernel internal
> > functions would be really nice. Probably wouldn't take too long to
> > have most of the major ones if someone were to volunteer to collect
> > the kernel-man pages and ask people to write just one. I'm too busy
>
> I'm your volunteer. I am relatively new to Linux development, but think
> I could handle assembling the man pages. So, to anyone interested in
> writing one, please let me know. I will assume that in the case of
> developing apps where different people are working on different
> functions, there is some existing method for posting items that are
> needed and letting people know what's not. Since I haven't been involved
> in such a development, I'm not aware of that method. If someone could
> fill me in, I'd appreciate it. From my own thoughts, I could post needs,
> haves, and completed files on my web page:
> (http://www.mindspring.com/~thrasher)
>
> Thanks,
> Bryan Thrasher
I don't man pages are necessary. But commenting internal
structures in the kernel and providing rationale is very useful.
I'd rather work on commenting the code (if you can automatically
derive man pages from code, fine; but I'd rather not see two
independent sets of documentation).
Most of the code is very understandable, but we can clearly spell
out what's going on...
I looked at kernel/fork.c...at the top it says:
/*
* 'fork.c' contains the help-routines for the 'fork' system call
* (see also system_call.s).
* Fork is rather simple, once you get the hang of it, but the memory
* management can be a bitch. See 'mm/mm.c': 'copy_page_tables()'
*/
where's mm/mm.c? (oh, memory.c....)
Pretty much every global variable should have an comment stating
what the reason for the initial values are and what it means...
marty
leisner@sdsp.mc.xerox.com
Member of the League for Programming Freedom