First of all, you misquote me so I'll set the record straight.
The above statements which you quote in effect state that I am
saying something along the lines that "GGI is the only way, and
that it SHOULD be done like that", and also that I am trying to
decide how things should be done.
Both are false. For the record, here is what I originally
posted:
> And there isn't. GGI isn't just a huge bloated kernel patch.
> It is a small kernel patch with userland libs. The kernel
> part of GGI is called KGI and only puts into the kernel stuff
> that HAS to be in the kernel.
Now that I've said that, let me clarify exactly what it is that
I'm saying.
I personally favor the idea of GGI, but I also favor the idea of
it being a CONFIG TIME OPTION. In other words, you select GGI at
compile time should you so desire, and if not, you pick the old
console code, etc... So in no way whatsoever do I think that GGI
should be shoved down anyone's neck, nor that I should decide
anything about the kernel at all.
Furthermore my statement above merely states that GGI only puts
into the kernel that which *should* be there. Let me clarify
that by saying "that which should be there *WHEN* using GGI". So
in other words, (by my understanding anyways) the GGI project is
ONLY putting into the kernel the necessary functionality that
must be in the kernel in order for GGI to function. They are not
bloating it with code that could be in usermode.
That isn't to say that GGI SHOULD be in the kernel - that is a
personal preferance, and not one that I'm deciding for everyone.
My personal preferance of what should or shouldn't be in the
kernel will not make one microounce of difference in what is
actually decided to be in the kernel. It is an opinion that KGI
is something needed in the kernel as an option to those who want
it, and nothing more.
> mharris> GGI isn't just a huge bloated kernel patch.
> mharris> It is a small kernel patch with userland libs. The kernel
> mharris> part of GGI is called KGI and only puts into the kernel stuff
> mharris> that HAS to be in the kernel.
>
> Then show us what needs to go into the kernel .... OpenGL does not.
Where do I state anywhere anything at all about OpenGL, let alone
putting it into the kernel?
Once again, I'm stating that: If one likes the idea of GGI, one
can rest assured that once it is implemented, only code that must
execute in kernel mode, will be in there. This does not include
drawing circles and other code which will be handled in usermode.
Read the GGI webpages, its pretty simple to understand really.
To prove my point further, here are the two kernels that I use.
Both are configured IDENTICALLY, with the exception that one
contains the GGI patches and the other does not.
-rwxr-xr-x 1 root root 382815 Nov 14 20:28 z2-0-30.k5*
-rwxr-xr-x 1 root root 382146 Dec 18 02:22 z30ggi*
As you can see, with identical kernels, the GGI kernel for some
reason is *SMALLER* than the non-GGI one. This may or may not be
a coincidence, however I just checked on a hunch and found out
the GGI one was smaller. YRMV.
> mharris> GGI is fairly simple IMHO. It will also be very powerful.
>
> I can add the same lines to fbdev, now where does that leave us?
Well, I can't say much about fbdev as I know nothing of it. I
can say however that losing my console video and keyboard due to
a SUID SVGAlib application gone astray is a big pain in the ass,
and IMHO is due to a big LACK in the video/keyboard code in the
kernel.
.... and so the argument goes.... The operating system's job is
to arbitrate access to hardware, and to make sure that user
applications cant take the system down. Applications should not
have direct hardware access to devices that could potentially be
security holes and/or cripple access to the system.
I've had many SVGAlib apps, as well as Xwindows screw up my video
and keyboard on way too many occasions.
The KERNEL should control video mode switching at a bare minimum
IMHO. This is only *MY* opinion however, and I'm certainly not
shoving it at anyone. I personally believe that it should be
that way however, and so far that the GGI project will be
something fantastic for many linux users.
I've got 64Mb of RAM in my system, and if KGI takes up less than
200k of kernel code, I'm happy. I'm sure it will make many
others happy as well. Those that don't want/cant afford to cough
up to 200k of memory for "kernel bloat" should pick "NO" to GGI
when compiling a kernel and be all the happier.
I'm sure that KGI will take up FAR less than 200k however. I bet
it is less than 50k when done. This is very acceptable *TO ME*
anyways.
Even if GGI doesn't get into the mainstream kernel, I have a
great feeling that it will become a necessary kernel addon for
lots of software that will come out, and eventually a necessity
for many people.
I'm not much into arguing about the kernel inclusion issue, as it
is only a religious issue. Ultimately the people will want it,
or they wont, and Linus will be the decision maker. Either way,
we WILL have GGI available officially, or unnofficially.
Perhaps a better name for GGI would have been KVI - Kernel Video
Interface.
> mharris> It is hard to judge something that is not complete, however a
> mharris> lot of people certainly judge GGI without having even read
> mharris> their webpages, mandate, etc...
>
> mharris> Once one has read their stuff, it makes sense. Some
> mharris> questions still arise, but it is NOT a bad thing like many
> mharris> people make it out to be (without reading the web pages).
>
> Well we had Geert try it out as an alternative to fbdev and it was not
> very promising. This of course does not say that GGI hasn't become a
> lot better (I belive it has) but I still need some good arguments to
> convince me that GGI will actually do what we need at a reasonable
> speed.
Well, it's hard to make an endall beall decision about something
that is an alpha project. So far, BASED ON THE GGI WEBPAGES, and
they're mandate, as well as experience using GGI, I think it is a
good thing. My opinion may change entirely as time goes on
however and I'm not 100% on it at all. I'm about 75% so far.
Once it is out of alpha and in to beta we will be much more able
to make a sensible decision.
> I do agree entirely with Alan when he says that bits from both camps
> will be the right solution in the end.
As do I. I have a strong feeling that in the end, regardless of
what happens, Linux's best interests will be at heart, and we all
will benefit. I've yet to see something go into the kernel that
ended up doing anything bad (other than little bugs).
> I will try to find some time and get in sync with your pages though.
Well, they're not my pages (GGI), but I certainly am morally
backing their efforts so far.
Where can I find out information about fbcon? Do you have a URL?
Take care.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu