Mike> Now that I've said that, let me clarify exactly what it is that
Mike> I'm saying.
Mike> I personally favor the idea of GGI, but I also favor the idea of
Mike> it being a CONFIG TIME OPTION. In other words, you select GGI
Mike> at compile time should you so desire, and if not, you pick the
Mike> old console code, etc... So in no way whatsoever do I think
Mike> that GGI should be shoved down anyone's neck, nor that I should
Mike> decide anything about the kernel at all.
Sorry, but isn't that a pretty bad idea. If it is decided to go the
GGI way (or some other way for that sake), I think the chosen solution
should cover all cases. Having this as a config option would mean a
lot of duplicated code and at least to me it indicates that a given
solution is not good enough as it does not solve the problems (this
applies to any solution - I don't think we should have two console
systems in the kernel, except maybe for a certain development time).
Mike> The KERNEL should control video mode switching at a bare minimum
Mike> IMHO. This is only *MY* opinion however, and I'm certainly not
Mike> shoving it at anyone. I personally believe that it should be
Mike> that way however, and so far that the GGI project will be
Mike> something fantastic for many linux users.
We do not disagree on the video mode switching, its already in the
kernel (for some architectures).
Mike> I've got 64Mb of RAM in my system, and if KGI takes up less than
Mike> 200k of kernel code, I'm happy. I'm sure it will make many
Mike> others happy as well. Those that don't want/cant afford to
Mike> cough up to 200k of memory for "kernel bloat" should pick "NO"
Mike> to GGI when compiling a kernel and be all the happier.
If GGI ends up requiring 200KB, then something is definately wrong
with it in my oppinion. We should shoot for having one console system
and if that is too big to be used on the smaller machines then I
consider it to be broken, telling people to buy more RAM is not an
option and a config option is a very bad solution on the long term.
Mike> Even if GGI doesn't get into the mainstream kernel, I have a
Mike> great feeling that it will become a necessary kernel addon for
Mike> lots of software that will come out, and eventually a necessity
Mike> for many people.
If this becomes the result we end up in a very unfortunate situation,
it would be like one should go and get an alternative TCP stack in
order to talk to some systems.
Mike> I'm not much into arguing about the kernel inclusion issue, as
Mike> it is only a religious issue.
Sorry, but that is very wrong - kernel inclusion means that it will
solve a problem or provide a resource that has to be in the
kernel. Including a wrong solution is not going to do anybody much
good - speaking out of principle here.
>> I do agree entirely with Alan when he says that bits from both
>> camps will be the right solution in the end.
Mike> As do I. I have a strong feeling that in the end, regardless of
Mike> what happens, Linux's best interests will be at heart, and we
Mike> all will benefit. I've yet to see something go into the kernel
Mike> that ended up doing anything bad (other than little bugs).
Good, what really annoys me with the whole thing about GGI is that
whenever people bring iy up on linux-kernel it is always presented as
the ultimate solution we should just sit down and wait for. It may be
a good solution in the _end_ (I am personally still not convinced it
will be), however in its current state it is not.
Mike> Well, they're not my pages (GGI), but I certainly am morally
Mike> backing their efforts so far.
Mike> Where can I find out information about fbcon? Do you have a
Mike> URL?
I think Geert's got something on his pages, but currently the server
seems to be down. The code is mainly in the vger snapshots (the stuff
in the official kernel from Linus is not fully uptodate), take a look
at drivers/video (some of these drivers are not very advanced yet) and
drivers/char/fbmem.c.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu