Pradhap Nirmal Natarajan wrote:
> Thanks all for your responses and suggestions. I also suggest more
> comments and documentation along the code rather than a separate doc.
> I am not sure if there is a review process for new commits but it
> will be great if we can stick to minimal set of do
Danny Mayer wrote:
> Richard B. Gilbert wrote:
>
>>It's never easy to wrap your mind around someone else's code, especially
>>when there's that much of it. It's even tougher if you're not really
>>fluent in C. I can struggle though it but I'm not what you'd call fluent.
>>
>>Rather than writin
Richard B. Gilbert wrote:
> It's never easy to wrap your mind around someone else's code, especially
> when there's that much of it. It's even tougher if you're not really
> fluent in C. I can struggle though it but I'm not what you'd call fluent.
>
> Rather than writing a separate document, I
Thanks all for your responses and suggestions. I also suggest more
comments and documentation along the code rather than a separate doc.
I am not sure if there is a review process for new commits but it
will be great if we can stick to minimal set of documentation
guidelines. I am sure this
Richard,
May I recommend the skeleton appendix in the RFC draft along with the
main text and flow diagrams. More detailed diagrams are in the UDel
report cited in the RFC. I took great care in commenting the protocol
and crypto source code, expecially since some of my code is fifteen
years old
Hal,
There is a page in the documentation on how to write a reference driver.
It's old, but mostly correct.
Dave
Hal Murray wrote:
>>I had my computer count the lines of code in one of the older versions,
>>about two years ago. 70,000 or so lines of code may be a small number
>>to you but it
>I had my computer count the lines of code in one of the older versions,
>about two years ago. 70,000 or so lines of code may be a small number
>to you but it seems like a lot to me. I once looked at the code for the
>Motorola Oncore driver to try to understand what was going on and failed.
It h
Harlan Stenn wrote:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Prathapnirmal) writes:
>>>
>
> prathapnirmal> Hi All, Which will be the best document to refer if I need to
> prathapnirmal> know information about the organization of code in ntp?
>
> And the answer is...
>
> prathapnirm
>Would such a document really be all that useful? It seems to me that the
>codebase is pretty small, and it should not be all that hard to figure out.
I use
grep whatever *.c
or
grep whatever -r .
If that doesn't work in the directory I'm working in,
then I cd .. and try again. After doing t
>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Prathapnirmal) writes:
prathapnirmal> Hi All, Which will be the best document to refer if I need to
prathapnirmal> know information about the organization of code in ntp?
And the answer is...
prathapnirmal> One obvious way is to look at the
Hi All,
Which will be the best document to refer if I need to know information
about the organization of code in ntp? I am looking for information like,
* a convenience library is created in libopts directory which is further
used to link against the final exe
* a library is created in libntpd to
11 matches
Mail list logo
