[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Reference Clock code for Windows - How can I
From:       Danny Mayer <mayer () ntp ! org>
Date:       2008-04-28 2:32:34
Message-ID: 48153742.1040208 () ntp ! org
[Download RAW message or body]

William Horner wrote:
> Thanks for your quick response.  Yes, I am modifying the type 27
> ARCRON clock.
> 
> Sorry for being a complete novice in terms of contributing to such a
> project.  How should I send in modified code? Warts and all?  Like I
> have already said - there are some warts that need removing and I am
> more than happy to remove them under your guidance.
> 

Add it as an attachment to the bug report.

> Do I just attach code to an email?  Will such an email get through
> your filters?  If so, I will prepare it this afternoon or Monday
> evening.  I haven’t attached it here so that I know that this
> message gets through.
> 

Attachments are always stripped from email and in any case is 
inappropriate for any mailing list.

> The two basic issues that I have are:
> 
> 1) The two current functions "refclock_open()" and "tcsetattr()" in
> win32_io.c both have the line
> 
> dcb.fDtrControl = DTR_CONTROL_DISABLE;
> 
> The ARCRON clock needs this line changing to:
> 
> dcb.fDtrControl = DTR_CONTROL_ENABLE;
> 

I consider that change extremely odd. I'm not an expert in this area but 
maybe Martin could comment on this.

> I have hacked the code directly at the moment to make it happen.  But
> that would break everything else for anyone else.  I need a way of
> being able to set this in the Windows code in a UNIX compatible style
> from the refclock code.  I see three possibilities: a) Find the UNIX
> function that would normally be able to enable/disable DTR control
> and reimplement it in win32_io b) Find out that one of the existing
> win32_io functions would normally be able to take a parameter for DTR
> and we can then modify the existing code accordingly.  I could well
> be missing the obvious.  Everyone is then happy. c) Something else
> that you might want to do instead.

I'd need to understand what the code is doing and what you need to change.

> 
> Which ever way, I am happy.  So long as I can enable the DTR from the
> refclock code and I can remove my hack.
> 
> 2) In my code I expose "io_completion_port_write()" as an extern, so
> that I can replace "write" with something compatible with your
> implementation of the Windows NTP asynchronous IO.  I prefer to do it
> this way rather than repeating all the code required to set up an
> Async WriteFile directly in the ref clock (would probably make it
> unreadable for non-Windows people).  My problem with this is the need
> to combine the WriteFile returned value and the GetError() result and
> then the ability to get coherent error codes back to the refclock.
> Is it possible to change the arguments on this function so that I can
> return the "GetError()" results from immediately after doing the
> WriteFile back to the refclock via reference?  I am assuming that it
> is reasonably safe to do something here because we know no-one else
> is using it because there is currently no "extern" defined?
> 

You shouldn't need to be doing all of this. I suggest you take a look at 
the hopfpci refclock which has some special code for Windows usage. You 
shouldn't need to be doing what you are doing.

> I have also made a few other IO completion port changes because the
> listening thread isn’t handling non-socket writes correctly - it is
> trying to close them with the WSA socket functions which doesn’t
> work on my system.  I have also put in more threads because I don’t
> like the idea of slow serial ports and sockets sharing threads.
> Whether or not you use that part in the -dev distribution is up to
> you but the changes that I have made are not experiencing the
> problems documented in the comments in the code. (I also renamed one
> of the io completion port functions to stop confusing myself - but
> that is exactly what I did that for - to stop confusing myself while
> finding my way around your code.  I do not in any way expect you to
> make that change into the -dev release!)
> 

This sounds like you don't have the last set of fixes that I had made in 
the completionports code, though it's hard to know based on you comments 
here.

Danny
_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers

[prev in list] [next in list] [prev in thread] [next in thread]