linux-kernel - Re: + pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspen d-vt-switch.patch added to -mm tree

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080313074332.GA19117@elf.ucw.cz>
Date:	Thu, 13 Mar 2008 08:43:32 +0100
From:	Pavel Machek <pavel@....cz>
To:	Jordan Crouse <jordan.crouse@....com>
Cc:	akpm@...ux-foundation.org,
	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	mm-commits@...r.kernel.org, dilinger@...ued.net, adaplas@....net,
	dilinger@...ian.org, rjw@...k.pl
Subject: Re: +
	pm-gxfb-add-hook-to-pm-console-layer-that-allows-disabling-of-suspen
	d-vt-switch.patch added to -mm tree


> > > (Note: I'm not convinced that console_sem is the best way to protect this, but
> > > we should probably have some form of locking..)
> > 
> > I guess this is okay for now, but we probably want to make it more
> > elaborate in future.
> > 
> > Console switch is there to make sure kernel (not X) owns the graphical
> > hardware.
> > 
> > That is unneccessary for gxfb since X never owns graphics hardware,
> > good. (I do not see why it is optional, then. Do you really want to
> > see tty1?)
> 
> Its the dream for the lxfb and gxfb to own the graphics hardware
> completely (at least, thats what Jim Gettys keeps pounding in to my
> brain), but we're not quite there yet.  What we have here are 
> framebuffer drivers that are intelligent enough to save and restore the
> state of the graphics engine, which is still a lot better then most other
> drivers.

Ok.

> > Now, question is what happens with two graphics cards, one of them
> > driven by X. Fortunately that is uncommon.
> 
> We would be screwed.  But since the Geode has built in graphics logic,
> it doesn't make much sense to use an external card, so we'll mostly
> avoid this problem.  But even if it happens, we'll have the VT switch
> available in a pinch.
> 
> > Also, it would be nice to make the logic the other way around. Move vt
> > switching to the drivers that need it because X can be expected to own
> > the hardware.
> 
> Conservation of energy.  Its easier to make 3 or 4 drivers opt out of 

Nice euphemism. You did quick hack instead of proper solution, and
someone will have to clean it up sooner or later...
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/