> > (1) Alpha Linux's console interface is, from what I can tell, i386
> > Linux's console interface (perhaps with a few tweaks).  They basically
> > said "these are PCs on speed."  That is quite simply _wrong_,
> > especially if there's any desire to support turbochannel frame
> > buffers.
> 
> From the basis of providing an familiar text-based user interface, I think
> the console interface is the simplest to program and subsequently use en
> route to providing better interfaces.

Huh?  I don't _care_ about the text interface.  That's simple, and has
a well-defined programmatic interface ("tty"/termios).  I'm talking
about the interfaces provided for frame buffer detection and direct
access.

As far as i've been able to discern, they are the same as the ones
used for the x86.

That makes them unacceptable for use on many alpha systems which
NetBSD supports.


> At the risk of sounding argumentative, you've repeatedly told us what the
> things you think the turbo-channel frame buffers _aren't_ without trying
> to tell us what you think they _are_.

Well, for a start, they are memory mapped, self-identifying, have no
I/O space, and have well-defined memory spaces.  However, that's
obvious to anyone who's worked with the TurboChannel bus.

In my opinion, the problem here isn't one of using the devices (that's
relatively easy).  It's one of identifying the devices and their
locations, and making it possible to share server/driver code between
those devices and e.g. their ISA/EISA/PCI counterparts (which may be
accessed via I/O space).

If i'm been saying what the TC frame buffers "aren't", it's because i
think that the current code makes assumptions which don't apply to
them, and am trying to point out ways in which it breaks or is
'losing.'

This continues below.


> > (2) the existing X server code in Xfree86 on the Alpha uses functions
> > 'inb()' and 'outb()', with their traditional arguments.  What do they
> > mean (what _can_ they mean) if you've got multiple ISA or multiple
> > primary PCI busses?  What do they mean on systems that look nothing
> > like PCs?
> 
> 'inb()' and 'outb()' map to a memory mapped input/output section on the
> alpha which interfaces to the ISA bus.  If you have multiple busses, it's
> up to the architecture specification to let you know how to talk to
> anything connected to the bus.

Right, but if write code which relies on functions which look like
'inb()' and 'outb()', then that code cannot be easily moved to another
bus architecture (or even another instance of the same type of bus in
a given machine).

On a system with multiple "I/O" spaces, no I/O space access functions
which use inb/outb-style arguments (i.e. port, data if outb) will be
sufficient to access multiple busses from the same piece of code.


That means that if you export those interfaces, or code to those
interfaces, it becomes harder to move code from one bus interface to
another.  For instance, to deal with multiple I/O spaces, you'd at
minimum have to recode your system to take an extra argument to all of
the inb/outb functions (which would undoubtedly be named something
different).

It also means that if you're used to dealing with hardware in one way
(e.g. I/O access) accessing it a different way (e.g. via memory mapped
access) becomse harder.


The inb/outb interfaces are just fine for PCs, where this is not a
concern.  However, on Alphas you _do_ have to deal with the potential
for multiple I/O spaces, for multiple access methods (e.g. memory or
I/O spaces) to standard system hardware, etc.


> I may be speaking totally offbase here, but as far as I can tell, XFree86
> was mostly developed for use on x86 machines, and those that are
> relatively architecturally similar.  ISA + PCI based Alpha systems fall
> close if not directly in with these.

Higher-end ISA + PCI Alpha systems are effectively _nothing_ like PCs.

TurboChannel systems are nothing like PCs.


NetBSD/Alpha already runs on the latter, and people are porting it to
the former.



> > (3) XFree86 is completely wrongheaded in the way it does frame bufffer
> > detection.  Basically, it looks through PCI configuration space (on
> > Alpha Linux by using some routines in libc(?), from what i can tell
> > reading the mailing lists), figures out what frame buffers are there,
> > where they are in /dev/mem, and accesses them that way.  _That_ is
> > totally wrong-headed, as well.  It might make sense for PCs, and on
> > OSes that have no reasonable console interface, but it doesn't make
> > sense on workstations or on systems with console interfaces which
> > actually do a fair bit of work (e.g. detecting generic 'classes' of
> > devices for you).
> 
> PCI configuration services are provided by the kernel and provide a
> standard interface for determining what is attached to the system, what it
> does, and where it's located relative to the memory and I/O bus.
> 
> 'cat /proc/pci' will gleam information such as the following on a PCI x86
> or alpha system:
>
> [ ... ]

Right, and this is, in my opinion, architecturally bad.

The right way to do this is to make each graphics device a real device
recognized by the kernel, i.e. with a standard set of names, say
ttyE*.  The X server should then look at all of those devices, ask
each of them "what kind of frame buffer are you," "how can I map your
memory," etc.

PCI actually makes this easier; since the device class/subclass
identification exists, it's possible to write generic drivers which
can recognize any pci video board and export its "relevant
information" (type/configuration information, I/O and memory spaces,
etc.; whatever.) to user-land without much trouble.

My point is that there should be no reason to look at something like
'/proc/pci' at all.  there should be no reason to access any device
node or file system entity other than the frame buffer devices
themselves to perform any operation on the frame buffer.
(Additionally, there should be no way to perform operations on _other_
devices via the frame buffer devices.)


Obviously, this doesn't necessarily make sense for all operating
systems supported by XFree86, but it should be _possible_ to use
facilities like the ones mentioned above in XFree86.

Other console interfaces and X servers have provided and used
interfaces like the ones mentioned above.  For instance, Sun frame
buffer devices are self-identifying, though they expect the X server
to know how to map them properly (since everything in that world is
memory mapped).


Any console interface that requires software to grovel for video
devices, is broken, in my opinion.  Any console interface which
requires direct access to system memory or I/O busses, or
configuration space (i.e. access via /dev/mem, or access through
bus-specific interfaces like inb() and outb() which aren't abstract
enough to be used on multiple busses) is also deficient, in my
opinion.




cgd