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

Rename ttyS* devices to correspond to node numbers #181

Closed
irdc opened this issue Jan 30, 2024 · 6 comments · Fixed by #190
Closed

Rename ttyS* devices to correspond to node numbers #181

irdc opened this issue Jan 30, 2024 · 6 comments · Fixed by #190

Comments

@irdc
Copy link

irdc commented Jan 30, 2024

Currently, the ttyS* devices don't correspond to the node they're connected to, e.g. /dev/ttyS4 corresponds to node 3. This is not necessary: this is a purpose-built system, and the fact that the BMC's SOC calls a certain UART something doesn't mean that the BMC firmware has to do the same. Renaming them would make things easier on users, who won't have to remember which device corresponds to which node.

I'd like to propose the following mapping:

  • /dev/ttyS0: for the BMC itself (the connection that's exposed on the Turing Pi as BMC_UART3)
  • /dev/ttyS1: Node 1
  • /dev/ttyS2: Node 2
  • /dev/ttyS3: Node 3
  • /dev/ttyS4: Node 4
@MPC-GH
Copy link

MPC-GH commented Jan 30, 2024

I think this was asked for before and wasn't accepted as a breaking change.

Could I make an alternative suggestion that an alias is put in along the lines of /dev/ttyNode1 though ttyNode4 or similar as an alternative way of sidestepping the ttySx not being Node X issue.

@srcshelton
Copy link

I'd support @irdc's proposal - even accepting that this is a breaking change, if we make it now in the early days of the product then it can be adapted to and we all move on.

The longer the (apparently) random mapping of TTY to node persists, the less possible it will be to fix without the degree of breakage becoming untenable.

I've got a script which maps nodes to ports, and I suspect many others will have followed the same approach - I'd gladly retire this if the port mappings were made human-readable.

Just imagine that there's a hypothetical future Turing Pi board which accepts even more nodes - would it make sense for the non-obvious ordering currently present to persist for all future products (for reasons of consistency) - or would it be best to nip this in the bud for now and the future at this point in time?

@CFSworks
Copy link
Contributor

See also #8

@soxrok2212
Copy link

I agree with @srcshelton. Best to make the change early.

@svenrademakers
Copy link
Collaborator

It's been a while since #8. A lot of breakage happened going into v2.0. lets update the tty's.

CFSworks added a commit to CFSworks/TP2-Firmware that referenced this issue Feb 12, 2024
New mapping:
ttyS0: BMC serial console
ttyS1-4: Serial connection to node 1-4

Closes turing-machines#181
@taxilian
Copy link

Agreed that it can cause some confusion, but I think anyone who is using the TTYs is going to be savvy enough to update things with the change -- and I seriously can't imagine how anyone would not prefer to have them defined in a simple, sane way. I have to look up the mapping every time I use them which is tedious

CFSworks added a commit to CFSworks/TP2-Firmware that referenced this issue Mar 18, 2024
New mapping:
ttyS0: BMC serial console
ttyS1-4: Serial connection to node 1-4

Closes turing-machines#181
@CFSworks CFSworks mentioned this issue Mar 23, 2024
12 tasks
svenrademakers pushed a commit that referenced this issue Mar 27, 2024
New mapping:
ttyS0: BMC serial console
ttyS1-4: Serial connection to node 1-4

Closes #181
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants