> 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).
Well, I don't know what the purists think, but I personally have
no problem with 20 different sets of console code to choose from.
So long as the one I like/need is an option, I'm perfectly happy.
I don't mind downloading a 40M source tarball either, even if it
takes 6 days to compile. That's just my opinion however, and I'm
sure others both agree with me, and I'm just as sure that many
people (especially on this list) disagree. I do however agree
with your suggestion that 2 systems could be merged into 1 over a
certain devel time. No doubt this will eventually happen.
> 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).
Without it, rogue apps can cause havoc on the system. One
example is this:
Xwindows, plus SVGAtextmode. When I start up X, it saves the
video card state. When I switch back to a text VC, then run
SVGAtextmode to change the text resolution, then switch back to
X, the next time I switch back to a VC, my new text mode is lost
because the X server only remembers the state the video card was
in when it started up.
The X server may or may not be able to be patched to remember the
console state on VC switches, that I do not know, however the
fact that an application is in control of this bothers me both as
a user, and as a programmer.
> 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.
Well, I was exaggerating on the 200k. Personally, I would accept
it though - when optionally CHOOSING GGI. Realistically I think
GGI is only a few k.
> 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.
And it very well could end up exactly like that too.. In the
world of free software, and GPL, etc... it opens the doors for
multiple different implementations of things. In reality Linus
will decide on Kernel issues, and he should. After all it is his
kernel, and we would not be enjoying the wonderful world of Linux
if it weren't for him. However there is another issue that could
arise - the distributions. If something such as GGI were to
become popular amongst users - but separate from the kernel,
someone else is likely to put out a distribution of the kernel,
or of a whole linux system that is GGI ready. For example
RedHat-GGI...
It is possible... I would like to see ONE kernel period, however
there are a few alternatives out there already... the Mach-linux
is one (mklinux?) I've seen others as well. Granted they are
not largely popular, and are special case, but something like GGI
*could* be popular in a certain niche such as games...
Just all speculation... I feel that the mainstream kernel will
adopt a good solution to the problem, wether it is GGI or
something else. I'd be much happier if only a few of the issues
were solved. Mainly console switching and video state NOT in
control of the application. Also video mode selection. Those
are my main quams...
> 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 agree. What I'm saying though is that regardless of the
correctness of either side of the argument, many people will hold
their ground religiously for whatever reasons rational or not,
and argue for arguments sake. I don't choose to go that deep
into such issues.
> >> 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.
Agreed. It looks very promising from my perspective, however I
don't necessarily understand all of the angles involved either.
> 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.
Ok, I'll have a look.
Take care.
TTYL
Mike A. Harris | Homepage: http://blackwidow.saultc.on.ca/~mharris
Computer Consultant |
I collect and browse commercial email sent to: root@127.0.0.1
RHIDE: The ultimate FREE programmers IDE for Linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu