Re: X11 per machine_arch not per port (Was: Moving ports across to X11R7)

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Feb 8, 2009, at 12:17 PM, David Brownlee wrote:

> On Sun, 8 Feb 2009, Michael wrote:
>
> > >         Is moving to X11R7 a good time to make X11 sharable per
> > >         machine_arch rather than per port?
> > >
> > >         At the moment only amd64, i386, macppc, shark, & sparc64 have
> > >         moved across, so...
> >
> > Should work for the client stuff at least. The only incompatibility  
> > I can think of right now is the way we mmap (PCI) IO space on  
> > powerpc and shark - by picking a magic address range which isn't  
> > used by any PCI device, on macppc it's 0xf2000000 ( traditionally  
> > the 1st PCI bridge's IO range ), prep and ofppc use different  
> > values, they're currently #defined in sys/params.h so there are no  
> > magic values or #ifdefs in the Xserver. We could just add an ioctl  
> > so the Xserver can ask the kernel where it would find IO space,  
> > that would take a few clock cycles more during setup but the result  
> > would be the same and Xservers would be compatible across  
> > $MACHINE_ARCH.
>
>         Is there any sense in adding it to the information exported by
>         /dev/fb? (I expect "no" is the answer here, but just checking).

We don't need it on sparc(64) - all the Sun graphics boards I've seen  
so far either map no IO space or have all the registers accessible via  
memory space too. We need it on macppc and shark for chips like the  
C&T 65550 or IGS CyberPro where only the blitter is memory mapped and  
all the rest is in extended VGA registers.

>         Having the kernel report the value definitely seems the cleanest
>         option - it would allow new ports to just use an existing Xwsfb
>         without needing to rebuild anything on the X side.

This has absolutely nothing to do with Xwsfb - it's for mapping IO  
register space which an Xserver like Xwsfb wouldn't know or care  
about. Failure to mmap IO space is non-fatal for exactly the reason  
you stated.

>         Another option might be to provide it via a machdep sysctl value?

I fail to see the advantage over an ioctl - it's not like this is a  
value which users should be able to change.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSY8emspnzkX8Yg2nAQIVdwf+OD3TYeKYWMnd59vsryOL3lRjr6pmm6MK
jX9AqYf7uYy9K46mQwWIkz46EBXpJxWmQkNYSHOWDfTG57pOIuWdQuDb15b/zJMw
ql+NK6fZkkm4WKRxiD0go3lWBByIS44i4lUvXvyAibnzSSaQefeOffoJa7OfVKbv
v52KlNOP3dbyTZN+4DAbr3r8V1Im5Tewr5Umw/FgjgO2hrxiFA9QDUWoUmh5FDo4
DCboA5R2WhvvuXjr9ox55ntExlagwwmxP21OIJbD4srhGR9zVWUc3CbaN9JcSDnF
xFY+8IrkV62HAy4JCk8Odhy7/VwnOiGJwX+lO5eFHDW4+XN9/kSesw==
=gWY+
-----END PGP SIGNATURE-----