From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: davem@davemloft.net, linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
Date: Thu, 06 Jul 2006 09:01:04 +0800 [thread overview]
Message-ID: <44AC60D0.7030107@gmail.com> (raw)
In-Reply-To: <200607060020.k660Krv1009111@harpo.it.uu.se>
Mikael Pettersson wrote:
> To: davem@davemloft.net
> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
>
> In recent sparc64 kernels, starting a 32-bit mode X server on
> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
> an Ultra5, results in the kernel complaining:
>
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
>
> That's FBIOGTYPE and FBIOGATTR. These errors occur because
> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
> arch/sparc64/kernel/ioctl32.c handled them for all devices,
> but 2.6.15-rc2 dropped that support and changed SPARC-only
> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
> However, drivers for framebuffers like the Mach64 that can exist
> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
> no longer accepted from 32-bit mode processes. Hence the errors.
>
> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
> to sbusfb_compat_ioctl when running in a sparc64 kernel with
> compatibility for sparc32 user-space, and to compile and link
> sbuslib.o with the frambuffer driver.
>
> A complication is that sbuslib.c doesn't compile on non-SPARC
> machines, so we must be careful to only enable it in the case
> described above. That's why the patch puts an ugly "if" statement
> in the Makefile.
Why not something like this?
1. In Kconfig
config FB_SBUSLIB
tristate
default n
Then all the sbus drivers will have this:
select FB_SBUSLIB
and atyfb will have this
select FB_SBUSLIB if SPARC64 && COMPAT
2. In Makefile
obj-$(CONFIG_FB_SBUSLIB) += sbuslib.o
3. In sbuslib.h
#ifdef CONFIG_COMPAT
int sbusfb_compat_ioctl(...);
#else
#define sbusfb_compat_ioctl NULL;
#endif
This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
cg* drivers and atyfb.
Tony
WARNING: multiple messages have this Message-ID (diff)
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: davem@davemloft.net, linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
Date: Thu, 06 Jul 2006 01:01:04 +0000 [thread overview]
Message-ID: <44AC60D0.7030107@gmail.com> (raw)
In-Reply-To: <200607060020.k660Krv1009111@harpo.it.uu.se>
Mikael Pettersson wrote:
> To: davem@davemloft.net
> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
>
> In recent sparc64 kernels, starting a 32-bit mode X server on
> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
> an Ultra5, results in the kernel complaining:
>
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
>
> That's FBIOGTYPE and FBIOGATTR. These errors occur because
> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
> arch/sparc64/kernel/ioctl32.c handled them for all devices,
> but 2.6.15-rc2 dropped that support and changed SPARC-only
> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
> However, drivers for framebuffers like the Mach64 that can exist
> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
> no longer accepted from 32-bit mode processes. Hence the errors.
>
> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
> to sbusfb_compat_ioctl when running in a sparc64 kernel with
> compatibility for sparc32 user-space, and to compile and link
> sbuslib.o with the frambuffer driver.
>
> A complication is that sbuslib.c doesn't compile on non-SPARC
> machines, so we must be careful to only enable it in the case
> described above. That's why the patch puts an ugly "if" statement
> in the Makefile.
Why not something like this?
1. In Kconfig
config FB_SBUSLIB
tristate
default n
Then all the sbus drivers will have this:
select FB_SBUSLIB
and atyfb will have this
select FB_SBUSLIB if SPARC64 && COMPAT
2. In Makefile
obj-$(CONFIG_FB_SBUSLIB) += sbuslib.o
3. In sbuslib.h
#ifdef CONFIG_COMPAT
int sbusfb_compat_ioctl(...);
#else
#define sbusfb_compat_ioctl NULL;
#endif
This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
cg* drivers and atyfb.
Tony
next prev parent reply other threads:[~2006-07-06 1:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 0:20 [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer Mikael Pettersson
2006-07-06 0:20 ` Mikael Pettersson
2006-07-06 1:01 ` Antonino A. Daplas [this message]
2006-07-06 1:01 ` Antonino A. Daplas
2006-07-06 19:35 ` Daniel Smolik
2006-07-07 7:17 ` David Miller
2006-07-07 7:30 ` Daniel Smolik
2006-07-07 9:30 ` David Miller
2006-07-07 10:09 ` Daniel Smolik
2006-07-07 10:15 ` David Miller
2006-07-07 10:25 ` Daniel Smolik
2006-07-07 10:30 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2006-07-06 1:44 Mikael Pettersson
2006-07-06 1:44 ` Mikael Pettersson
2006-07-06 3:52 ` David Miller
2006-07-06 3:52 ` David Miller
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=44AC60D0.7030107@gmail.com \
--to=adaplas@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=sparclinux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.