| 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
| ||
|
Date: Fri, 19 Feb 2010 08:10:49 -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> 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: > I don't want to change the existing values as they are somewhat visible > to user space. Sorry if I was unclear - I wasn't talking about changing the value, I was just saying that VT_ACKACQ and VT_PROCESS_AUTO are used in different contexts, so it shouldn't matter that they have the same value. One thing that probably would be nice though would be to move the VT_ACKACQ define to a different place in vt.h (probably after the VT_RELDISP define). > Yes. You could use the VT_EVENT facility for the switch monitoring but > the asynchronous nature of the reporting probably isn't what is needed > for input device switching etc. Yeah, it looks like the X server would have to be constantly blocking inside a VT_WAITEVENT ioctl in order to use that, and then it wouldn't be getting anything else done. :-/ 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/
Powered by blists - more mailing lists