>Actually, running in user space adds two problems:
>
>1) Performance degradation as a result of protection
> domain crossing which does not exist in the current
> implementation
So, you seems to be effectively saying that any program running in the
lower priority in the user-lan
Kazutaka YOKOTA wrote:
> >> I propose to have user-land screen savers instead of KLD
> >> screen savers.
> >
> >[ ... "performance degradation" ... ]
> >
> >[ ... "file access" ... ]
> >
> >I don't see either of these as being compelling arguments
> >in favor of a user space implementation; I gues
> It is much easier, at least to me, to just remove much of the KLD
> screen saver support from syscons to the user-land, than to utilize
> the kthread :-)
Just FWIW, I think that moving the screen saver to userspace is an
excellent thing to do.
--
... every activity meets with opposition, eve
>You can stick the screen saver in a low priority kthread and achieve the same
>effect.
As the screen saver accesses and uses syscons' internal structures and
facilities, its operation must be carefully coordinated with syscons.
Thus, putting the screen saver in a kthread will require major
restr
>> I propose to have user-land screen savers instead of KLD
>> screen savers.
>
>[ ... "performance degradation" ... ]
>
>[ ... "file access" ... ]
>
>I don't see either of these as being compelling arguments
>in favor of a user space implementation; I guess this means
>you want to do file access
On 24-Jul-01 Kazutaka YOKOTA wrote:
> This is to propose to abolish KLD screen saver modules.
>
> KLD screen savers have the following problems/deficiencies.
>
> - It is too easy to abuse the power of being run in the kernel
> mode. The screen saver is invoked periodically once the console
>
Kazutaka YOKOTA wrote:
>
> This is to propose to abolish KLD screen saver modules.
>
> KLD screen savers have the following problems/deficiencies.
[ ... ]
> I propose to have user-land screen savers instead of KLD
> screen savers.
[ ... "performance degradation" ... ]
[ ... "file access" ...
In standard FreeBSD the moving of screen savers to userland may
not be a big deal. In Embedded applications it is nice to be able
to create very lightweight (read size) screen savers. Hopefully
this new mechanism will still allow this. (-;
Larry
--
---
Hi, a friend of mine just forwarded this to me. I've just been looking
at writing graphical stuff, firstly screen savers for the console
using vgl. In fact we were talking about this exact idea just last
week. (As my code doesn't like being run in the kernel - because while
it's in devel it still
On Tue, Jul 24, 2001 at 21:34:40 +0900, Kazutaka YOKOTA wrote:
>
> >> We shall provide the "screen saver daemon" and a set of "screen saver
> >> programs." The screen saver daemon will run in the background and
> >> periodically checks if the console is idle. When it finds no
> >> activity in t
>> We shall provide the "screen saver daemon" and a set of "screen saver
>> programs." The screen saver daemon will run in the background and
>> periodically checks if the console is idle. When it finds no
>> activity in the console, it will launch a specified "screen saver
>> program."
>
>No "
On Tue, Jul 24, 2001 at 21:07:40 +0900, Kazutaka YOKOTA wrote:
> I propose to have user-land screen savers instead of KLD
> screen savers.
Good idea.
> We shall provide the "screen saver daemon" and a set of "screen saver
> programs." The screen saver daemon will run in the background and
> p
12 matches
Mail list logo
