Page MenuHomeFreeBSD

sbin/init: merge ttys file down to single file
ClosedPublic

Authored by ehem_freebsd_m5p.com on May 13 2021, 10:22 PM.

Details

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.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

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).

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.

This revision is now accepted and ready to land.May 13 2021, 10:35 PM

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.

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.

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

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.

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

Do we really need to keep rcons?

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

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.