public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Januszewski <spock@gentoo.org>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Paulo Marques <pmarques@grupopie.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] video: uvesafb: Add X86 dependency.
Date: Wed, 12 Sep 2007 00:59:32 +0200	[thread overview]
Message-ID: <20070911225932.GA12223@spock.one.pl> (raw)
In-Reply-To: <20070911123159.GA23692@linux-sh.org>

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@im.gentoo.org
Gentoo Linux Developer                    http://people.gentoo.org/spock


  reply	other threads:[~2007-09-11 23:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11  8:17 [PATCH -mm] video: uvesafb: Add X86 dependency Paul Mundt
2007-09-11 11:41 ` Paulo Marques
2007-09-11 11:53   ` Paul Mundt
2007-09-11 12:19     ` Paulo Marques
2007-09-11 12:31       ` Paul Mundt
2007-09-11 22:59         ` Michal Januszewski [this message]
2007-09-11 23:09         ` [PATCH -mm] uvesafb: Don't access VGA registers directly when running on non-x86 Michal Januszewski
2007-09-12  0:44           ` Paul Mundt
2007-09-12 19:41             ` Michal Januszewski
2007-09-13  1:43               ` Paul Mundt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070911225932.GA12223@spock.one.pl \
    --to=spock@gentoo.org \
    --cc=akpm@linux-foundation.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox