lkml.org 
[lkml]   [2001]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The new X-Kernel !
    On Sun, Oct 21, 2001 at 09:33:34AM +0100, Jonathan Morton wrote:
    > > > Boots up with X, that means.
    > >
    > >I've never understood why people want X, StarOffice (OpenOffice) etc to be
    > >moved into kernel space :) IMHO it's strictly user space issue. You can
    > >start X or gdm/xdm/kdm from a boot script and so on. No kernel modification
    > >is needed for this.
    >
    > Probably because they don't know the difference between kernel and
    > user space. Kinda understandable when you come from a Mac or Windows
    > background, where (in the former) there is no distinction or (in the
    > latter) it's so blurred as to make little difference.

    Hmmm, I don't know Windows very well but AFAIK it's something microkernel
    architecture (well this makes me laughing always though :), HAL, and so on.
    But even the GUI of windows can be changed but it's more hard to implement.

    > And if they *do* understand it, from a dispassionate point of view,
    > it does seem to make sense to put graphics drivers in the kernel -
    > they're implemented as "device drivers" in every other desktop OS.
    > Except MacOS X, where's it's an application layer like glibc, but
    > nobody understand OS X yet beyond the hardest of developers.

    :) It would be interesting to learn more on it (if infomartion is available).
    afaik it's a unix like system in its core.

    > But they don't realise that XFree86 has an *enormous* amount of
    > developer time behind it, which would need to be duplicated to make
    > it work in kernel space with full backwards compatibility. Oh, and
    > did I mention this would all be for one platform - XFree86 is
    > designed to run on many! It would also bloat the kernel tremendously.

    Hmmm. It quite complex question. Let's think about direct rendering kernel
    modules ... XFree 4 went a step closer to the "right solution(TM)" because
    it can cooperate with low level rendering capabilities of direct rendering
    modules can be found in newer Linux kernels. And I think it's right to
    split functions of a driver into "kernel level" and "user level" parts based
    on functionality and hw access needs of particular parts of the whole gfx cloud.
    However this "splitted" design can cause problems. Nowdays, XFree4 uses
    OS independent, separated drivers (on a different OS but with the same CPU
    the driver module is the same for XFree. afaik this technique was donated by
    Metro). But kernel rendering modules are VERY kernel related stuffs and it's
    quite hard for a video hardware vendor to release binary only drivers for
    almost every kernels and so on. Of course the perfect solution would be open
    source (let's dream a bit: GPL) drivers but our world is far from being perfect :(

    Also it would be nice if frame buffer can support 3D hw accelerated gfx functions.
    And so on. So probably a better interaction should be implemented between
    various gfx elements of a tipical Linux system. [I don't know GGI very well
    but AFAIK its goals are very interesting]

    But this is far from the original topic of this thread so I must say: sorry :)

    - Gabor
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:08    [W:4.207 / U:0.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site