sbin/init: merge ttys file down to single file

[ehem_freebsd_m5p.com]

Summary

The tty lists were already pretty similar and there hadn't been any real
need for them to remain distinct for some time. As such merge to a
single file.

The Xen and RISC-V consoles are being preserved. For systems using them
they are crucial, for other systems the devices won't exist and their
presence in /etc/ttys is harmless. The XDM line from x86 was the one
chosen.

[ehem_freebsd_m5p.com]

Follow on for D29873. Clearly the ttys files have been slowly converging, so perhaps it is finally time to go ahead and merge them into a single file.

Some notes: I'll confess I haven't actually confirmed a full build with this yet, so if the Makefile is subtler than expected I may have broken it (and will update later). Second, there is room for argumentation about device order in /etc/ttys.

The greatest impact would be on MIPS since ttys.mips didn't have anywhere near as many devices listed as others. All the others already had ttyv0-ttyv8 listed (though the XDM lines for ttyv8 differed).

[imp]

This is pretty close to where I was headed when I started doing my diff reductions.
thanks for taking it the rest of the way.

[imp]

In D30256#679543, @ehem_freebsd_m5p.com wrote:

The greatest impact would be on MIPS since ttys.mips didn't have anywhere near as many devices listed as others. All the others already had ttyv0-ttyv8 listed (though the XDM lines for ttyv8 differed).

True, but MIPS doesn't have syscons or vt (IIRC), so it will be a nop there. That tty file was effectively forked when the onifexists didn't exist.

[ehem_freebsd_m5p.com]

Tested in a build and passed. Can be adjusted on commit, but I suspect this really should be titled "etc/ttys: merge ttys file down to single file". Grabbed the repository file location, instead of the output location when initially committing.

[mhorne]

This seems ready to go, but perhaps D29873 should become the child revision? I.e. cleanup first, addition second.

[ehem_freebsd_m5p.com]

In D30256#692969, @mhorne wrote:

This seems ready to go, but perhaps D29873 should become the child revision? I.e. cleanup first, addition second.

That is likely better, but may be better for fixing during commit.

[mhorne]

@imp do you care to commit this or shall I?

[jrtc27]

Do we really need to keep rcons?

[jrtc27]

Hm, never mind, I guess Spike doesn't end up with a ttyu0, only rcons?

[mhorne]

In D30256#699185, @jrtc27 wrote:

Hm, never mind, I guess Spike doesn't end up with a ttyu0, only rcons?

Yeah, I think this is the reason for it, but I'm not certain. I believe the SBI get/putchar methods are now deprecated (disappointing), so this will need to be looked at eventually. Perhaps rcons could be made into a proper uart driver, but this is hardly exciting work.