linux-kernel - Re: [PATCH -mm] video: uvesafb: Add X86 dependency.

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]

Date:	Tue, 11 Sep 2007 21:31:59 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Paulo Marques <pmarques@...popie.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Januszewski <spock@...too.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] video: uvesafb: Add X86 dependency.

On Tue, Sep 11, 2007 at 01:19:57PM +0100, Paulo Marques wrote:
> Paul Mundt wrote:
> >On Tue, Sep 11, 2007 at 12:41:49PM +0100, Paulo Marques wrote:
> >>[...]
> >>Why do you say that it's x86 specific? Am I missing something?
> >>
> >The emulator it uses only runs on x86 and x86_64. Thus, it's x86
> >specific. The v86d and uvesafb pages seem to be in disagremeent, unless
> >by 'non-x86' it's only implying x86_64.
> >
> >Additionally, it needs the vga I/O routines, as per vgacon. Most
> >platforms don't define these.
> 
> I just saw the v86d emulator code, and you're right. It mmaps /dev/mem 
> and assumes the video BIOS is mapped there.
> 
> We should try to change that to mmap something like 
> "/sys/bus/pci/devices/0000:01:00.0/rom" instead so that it can work on 
> any system with a video card plugged on a PCI bus.
> 
> It should also be possible for the emulator to translate in/out 
> instructions to appropriate memory mapped I/O equivalents, no?
> 
> Anyway, I think it is up to Michal to decide if we should remove the 
> kernel support for other archs, or let it stay a bit more while working 
> on solving the v86d side of things. So I'll just step aside now....
> 
Once v86d is fixed up to get at the ROM directly and the driver uses MMIO
directly, I don't see a problem with unrestricting it. For the time being
however, the build is both broken, and the emulator it uses won't run on
anything but x86, so I see no reason not to add a Kconfig dependency that
reflects this until such a time where it's no longer true.

At least if there's a set of restrictions on something fairly generic,
they tend to be visible, and they also tend to get fixed up over time. We
should however not enable something generically which at the moment is
very much tied to a single platform. Later patches can remove the
dependency at such a time that that assertion no longer holds true.
-
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/