Re: Console mapping problems? [I hear about these - I wanna know!]

H. Peter Anvin (
Fri, 12 Sep 1997 17:55:45 -0700 (PDT)

> I'm not sure what you mean by 'sources' here. Different
> manufacturers? Different types of video I/O?

Different data sources.

> > and the bandwidth of the data streams make it a unique case.
> OK, I will grant you this. But, *all* types of hardware have
> their own unique peculiaries and must be handled differently. Indeed, the
> bandwidth issue would seem to argue FOR kernel inclusion of video driver
> code, since that code will be foundational and a lot of other kernel
> subsections will interact with it. Those interactions can be much more
> highly optimized and tweaked when the kernel-user barrier doesn't need to
> be worked around. Look at NT 4.0. The video drivers weren't in the
> kernel in 3.51, but were moved into the kernel in 4.0, and they got a LOT
> of speed out of it.

> > However, when I say people are being too absolutist I mean both ways.
> > I'm quite happy going with whomever puts out the better solution
> > (XFree86 or GGI.) I'm just commenting on what I see.
> It hurts to be labeled an absolutist when we feel that we are
> simply following established OS design principles.

Well, there are a number of "established OS design principles" -- one
of them is "don't do it in kernel space unless you absolutely have
to." Linux has a problem with people trying to put way too many
things in kernel space, and putting a brake on that is usually

> > The flame from
> > about a year and a half ago ("we're going commercial" or something
> > like that) was the straw that broke the camel's back for a number of
> > people.
> That was an off-the-cuff remark born out of frustration. GPLed
> code cannot be 'taken commercial' in any case.
> > To be frank, I would be very hesitant to "defend the validity of
> > your ideas" in any *other* form than working code -- may it be fair or
> > not, you have exceeded your hot air quota by quite a bit.
> Indeed, and as I mentioned before I have, since the last GGI
> flamewar on this list, made a point of not even *mentioning* the GGI on
> this list - even when GGI-related issues came up, I bit my tounge and went
> back to coding. However, I WILL NOT stand idly by when attacks on or
> misstatements about the GGI are made, on this list or anywhere else. We
> have enough work ahead of us without having everyone in the Linux
> community considering us to be 'flakes' and 'full of hot air'.

Speaking personally; maybe you guys ought to consider making status
summaries ("this is what we have so far") and post them. I think the
perception is still pretty widely spread that since you didn't get
unconditional approval from the start, you went off in a huff.

That is, if you care.