Re: revocation of /dev/console at the end of rc sequence

On 26 Mar 2025, at 21:06, Warner Losh <[email protected]> wrote:
> On Wed, Mar 26, 2025 at 3:02 PM Andriy Gapon <[email protected] <mailto:[email protected]>> 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