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

[Michal Januszewski]

On Tue, Sep 11, 2007 at 09:31:59PM +0900, Paul Mundt wrote:

> > 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.

Just to clear things up: yes, at the moment v86d supports only
x86 and amd64 (aka x86_64) and yes, supporting other arches is
possible and planned.  The main limiting factors as far as this
is concerned are the little amount of my free time and the fact
that I don't currently have access to non-x86 hardware.

Please note that the kernel part (i.e. uvesafb) is meant to be
generic (it currently uses VGA IO ports on non-x86, which is a
bug and for which a patch will follow) and support or lack thereof
for a specific arch should be dependent on v86d only.

That being said, I think that having a kernel dependency 
tracking the development status of userspace code is generally
a bad idea.

Best regards,
-- 
Michal Januszewski                              JID: spock@xxxxxxxxxxxxx
Gentoo Linux Developer                    http://people.gentoo.org/spock

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