@werdahias highly depends on which BSD.

For example, FreeBSD and derivatives vs. normal BSDs. But then, NetBSD and OpenBSD may also have diverged from each other, and OpenBSD’s init procedure has changed from since when MirBSD forked…

Quick look at MirBSD:

• there’s no /etc/getty at all

• /etc/gettytab contains a few entries for serially attached hardware consoles but is mostly historical

• there is a /etc/ttys which contains a list of things like:

  # name  getty                           type    status          comments
  ttyC0   "/usr/libexec/getty Pc"         wsvt25  on  secure
  ttyC1   "/usr/libexec/getty Pc"         wsvt25  on  secure
  ttyC2   "/usr/libexec/getty Pc"         wsvt25  on  secure
  […]
  tty00   "/usr/libexec/getty std.9600"   unknown on
  tty01   "/usr/libexec/getty std.9600"   unknown off
  […]
  ttyp0   none                            network
  ttyp1   none                            network
  […]
  

  These list the virtual, serial and pseudo terminals, respectively; it’s comparable to the same section in inittab(5) in sysvinit. (There’s also an entry for “console” where I did some baudrate autodetection magic for MirBSD. One can use either that or the entries for ttyC0/tty00/both.)

• the ttys(5) file is read by init(8) after /etc/rc has run, with the functions from <ttyent.h> (libc), so the format is actually defined thereby

• new_session() in src/sbin/init/init.c prepares the argv[] for each getty for each line enabled in ttys (the “on” vs. “off”)

• multi_user() actually starts the gettys then via start_getty() but interrupts if there is “serious” trouble getting a getty to run

• the fork child opens the device with O_NONBLOCK before execing getty; (fd == -1 && (errno == ENXIO || errno == ENOENT || errno == EISDIR)) is considered “session shutdown”, not “serious trouble”; fd == -1 in other cases is not even considered an error (let getty handle that; the fd (or -1) is just closed, then getty execd); failure to pipe, fork, etc. is “serious trouble”

• if getty returns too quickly too often, the session on that terminal is put idle, with a huge warning, for a few minutes, then is retried

So it boils down to which devices are enabled in ttys and then either return ENXIO on open(2) or work.

@werdahias ah, and the device nodes under /dev always exist (in a normal setup), they are created by MAKEDEV at installation time.

@werdahias AIUI this is different for FreeBSD which has some kind of devfs.

@werdahias nah, the nodes always exist

@werdahias it’s like pre-dev{,tmp}fs Linux, the installer or MAKEDEV script creates a bunch of known nodes statically and some in reserve.

Again, not speaking for FreeBSD, only classic BSD.