Re: revocation of /dev/console at the end of rc sequence
- In reply to: Warner Losh : "Re: revocation of /dev/console at the end of rc sequence"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 26 Mar 2025 21:11:10 UTC
On 26 Mar 2025, at 21:06, Warner Losh <imp@bsdimp.com> wrote: > On Wed, Mar 26, 2025 at 3:02 PM Andriy Gapon <avg@freebsd.org <mailto:avg@freebsd.org>> wrote: >> On 26/03/2025 10:52 pm, Warner Losh wrote: >> > It's a control daemon for the video subsystem, which is unrelated to the system >> > console except maybe it will be used as the system console. But console-kit-daemon >> > doesn't care, if I understand, about the system console: it just wants to >> > control which >> > of the virtual terminals are current then? Is that a more precise way of saying >> > what it >> > does avoiding overloaded terms? >> >> Yes. In their own words, ConsoleKit2 is a framework for defining and tracking >> users, login sessions, and seats. >> In practice, at least on FreeBSD, that translates mostly to tracking active VTs >> (of the video console) plus logins via ConsoleKit2-aware programs such as >> various Display Managers. >> >> And I agree that "console" is a very overloaded term. >> E.g., comments in sys/sys/consio.h talk about "console" although it's pretty >> clear that the ioctl-s are for the video console. > > Yea, after all that I think /dev/ttyv0 is likely the least bad choice we have in the > absence of a better management device. That’s the conclusion I reached when fixing SDDM’s VT management, so it’s using /dev/ttyv0 when it needs an arbitrary device for VT control. Having a device that lets you do all the VT ioctls without also being a specific VT would be good, but /dev/ttyv0 is good enough in practice. Jess