Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blazer_soi: blazer driver, serial port over tcp/ip #116

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alezz
Copy link

@alezz alezz commented Apr 2, 2014

This is a version of blazer that allows the use of a ethernet to serial device, also called YPort.
Such a device allows a serial port to be connected to an existing ethernet network, and uses tcp to access the serial port. An example of this device is provided by Ethersex Project (http://www.ethersex.de); this driver extension has been tested with it.

@clepple clepple added the feature label Apr 4, 2014
@clepple
Copy link
Member

clepple commented Apr 4, 2014

Thanks for submitting this - it seems useful. However, the blazer driver will eventually be replaced by nutdrv_qx. Rather than add this code to individual drivers, what if it went into the core driver code?

There was an old patch which got misplaced during our move to Git. It allows the "port=" option in ups.conf to take a hostname:port pair to specify a TCP connection. I haven't compared the details of the code, but would this work with your device?

https://github.com/networkupstools/nut/tree/netport-on-2.7.1

Either way, we would need to provide a bit more documentation for end users.

@alezz
Copy link
Author

alezz commented Apr 6, 2014

Hi Charles,
Thanks for reply.
I've took a look at the code you suggested me and tested it with my device.
That patch implements tcp connection in serial.c, this is a more
flexible approach, as it is applicable to all serial drivers. However
the drivers then make ioctl calls to setup the tty port, and these fail.
At least, this is what happens to me with blazer_ser. Maybe the patch
has not been finished?
In my patch tcp is implemented only for blazer, but it works and it was
simple for me to write it.
About documentation, the man pages for blazer are sufficient, except for
the few parameters (variables) documented with "blazer_soi -h".

If the community thinks that would be useful, and we find out the best
implementing solution, I might think about improving this feature somehow.

On 04/04/2014 14:39, Charles Lepple wrote:

Thanks for submitting this - it seems useful. However, the blazer
driver will eventually be replaced by nutdrv_qx. Rather than add this
code to individual drivers, what if it went into the core driver code?

There was an old patch which got misplaced during our move to Git. It
allows the "port=" option in ups.conf to take a hostname:port pair to
specify a TCP connection. I haven't compared the details of the code,
but would this work with your device?

https://github.com/networkupstools/nut/tree/netport-on-2.7.1

Either way, we would need to provide a bit more documentation for end
users.


Reply to this email directly or view it on GitHub
#116 (comment).

@zykh
Copy link
Contributor

zykh commented May 12, 2014

Would it make sense to simply bypass ioctls/terminal-related actions?
Quick attempt at it (just for blazer/nutdrv_qx, at the moment):
https://github.com/zykh/nut/tree/netport

@clepple
Copy link
Member

clepple commented May 17, 2014

@zykh sorry I haven't had more time to comment on this, but the new netport branch looks good. We may want to have a few upsdebugx() calls during the netport setup, in case someone has a typo in their dev node name, and isn't expecting the network calls.

Also, did you happen to see why belkinunv was not using the serial.c shared code?

@zykh
Copy link
Contributor

zykh commented May 18, 2014

Added a debug line and removed fatal* calls.

belkinunv - there are 2 sets of functions:

  • one (used normally) relies on serial.c code,
  • the other one (used when the driver is called with the 'wait' flag/option, used as a workaround for a specific shutdown problem) doesn't, probably to avoid fatal* calls (it predates the introduction of the non-fatal versions of ser_* functions) and spurious logging messages.

@alezz, can you test blazer_ser/nutdrv_qx from the following branch?
https://github.com/zykh/nut/tree/netport

@alezz
Copy link
Author

alezz commented Jun 13, 2014

Hi @zykh . Sorry for my big delay in answering. Unfortunately due to lots of work to do I was not able to test it out and I'm not sure when I will have some minute to do that.

jimklimov pushed a commit to jimklimov/nut that referenced this pull request Aug 6, 2016
@jimklimov
Copy link
Member

Hi all, given that this adds a standalone driver, there seems to at least be no code-wise conflict with this PR despite its age. But the points raised in review earlier about possibly sharing and unifying code with other NUT parts, and parsing "port" commonly as an "IP:PortNum" value in particular, make sense.

So I need some team consensus: is this good to merge "as is" to add a new driver and refine later when someone is annoyed (e.g. also regarding new nutdrv_* naming standard) or should issues raised above be resolved before or shortly after a merge? CC @clepple @aquette @zykh @alezz

Also seems I can not update the source branch of this PR, to merge the current NUT master into it and have Travis CI take a bite.

@jimklimov jimklimov added the outdated-CI PR was made without rights for NUT Team to update its source branch, proposed codebase has no/old CI label Oct 9, 2020
@clepple
Copy link
Member

clepple commented Oct 11, 2020

@jimklimov As you mentioned, the original PR adds a standalone driver, but it is resurrecting the blazer_* code that we were trying not to maintain in parallel with @zykh's nutdrv_qx codebase, and it does not have a man page to describe the differences between it and the original blazer_ser driver.

I think if someone is truly interested in supporting serial-to-TCP adapters, they need to be willing to start from more recent code (such as @zykh's netport branch), and then test against actual hardware. I have neither the time nor the hardware to do it myself, so maybe take my comments with a grain of salt.

jimklimov pushed a commit to jimklimov/nut that referenced this pull request Nov 27, 2020
@jimklimov jimklimov marked this pull request as draft March 29, 2022 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature outdated-CI PR was made without rights for NUT Team to update its source branch, proposed codebase has no/old CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants