linux-kernel - Re: [PATCH] Add a new VT mode which is like VT_PROCESS but doesn't require a VT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <28568671.141471266580824918.JavaMail.root@zimbra>
Date:	Fri, 19 Feb 2010 07:00:24 -0500 (EST)
From:	"Ari G. Entlich" <atrigent@....neu.edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, atrigent@....neu.edu
Subject: Re: [PATCH] Add a new VT mode which is like VT_PROCESS but doesn't
 require a VT_RELDISP ioctl call

----- "Alan Cox" <alan@...rguk.ukuu.org.uk> wrote:
> If KMS doesn't need to mode switch then does it need any of this stuff-
> can it not just switch to a console and use it ? Otherwise please use a
> different value than ACKACQ (just for clarity) and conceptually it looks
> fine to me - I just question if it's really needed as KMS based X not
> having to play with magic locking stuff would be cleaner still.

I'm not positive I understand what you're saying. Are you asking why we can't
just use VT_AUTO now? That's something I investigated, and there are a couple
reasons why it wouldn't be suitable:

1. VT_AUTO doesn't send signals to anything when a VT switch happens, precisely
   because VT_AUTO is supposed to be used in the case where there's nothing to
   send signals TO (i.e. the VT is managed by the kernel). The X server still
   needs to know about VT switches to turn input devices off and such.
2. The kernel ignores VT switches when switching away from a VT which is in
   KD_GRAPHICS + VT_AUTO mode. I'm not sure what the reason for this is, and
   I'm also not sure why it doesn't ignore switches TO these sorts of VTs, but
   that's the reality and my impression is that it's generally not a good idea
   to change these sorts of things when they've been in place for this long.

Is this what you were asking about? Also, in terms of what you said about
VT_ACKACQ, it wouldn't really make sense for there to be a new VT_ACKACQ value,
because VT_ACKACQ is something which gets passed to a VT_RELDISP, and VT_RELDISP
isn't needed at all in this new mode.

I hope that clarifies things.

Thanks!

Ari
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/