Messages in this thread | | | From | mharris@ican ... | Date | Tue, 24 Feb 1998 06:29:06 -0500 (EST) | Subject | Re: GGI, EGCS/PGCC, Kernel source |
| |
> mharris> On 23 Feb 1998, Jes Degn Soerensen wrote: > >> There is also the question whether GGI is the right approach or > >> not! > > mharris> And there isn't. > > Of course there is. Everybody has the right to question the validity > of a new kernel subsystem, just because you happen to like a certain > approach it doesn't give you the right to decided what is right and > what is wrong.
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
| |