Re: Death sentence to KLD screen savers? Comments?
>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-land is the source of performance degrataion :-) >2) Inability to disable the screen saver in, for example, > a "panic" situation, where there is no opportunity to You may be thinking that we can put the video hardware back to the known state after ANY KLD screen saver has run. This is simply not true. It is simply that the KLD screen savers we currently have are well-behaved. Once you write a KLD screen saver which directly manipulates the video hardware in the way the console driver isn't aware of (and there is no mechanisms which will prevent you from doing this), it becomes impossible for the console driver to undo such operation. > return to user space and have the screen put back into > a known good state. This is analogous to the problem > we have diagnosing kernel panics while X11 is running > on the console: only the user space program can undo > what it has done, and we can not run the user space > program. The console driver cannot undo what the X server does, because the X server manipulates every bits of the video hardware to maximize its performance and the console has no control over this. IF the X server used olny console ioctls or touched generic VGA registers only, we could put the video card back to the known state when the kernel panics. It's true that you can write a user-land screen saver which touchs the video hardware (non-standard registers etc.) in a similar way to the X server. But, such screen savers won't be portable in the sense that it runs only on certain video cards, and breaks on the other. Therefore, you need to stick with console ioctls (and libvgl) to make it run on every hardware. # Of course, we don't have this problem with text-type screen savers # which may use escape sequences or ncurses. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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 guess this means > >you want to do file access in your screen saver(s). > > Both points/complaints/requests have been raised several times in our > mailing lists in the past. (Sorry, I don't keep copies.) I didn't say they weren't arguments, merely that I did not find them compelling. This looks to me like change for the sake of change. > Some people don't like cputime eaten up by the screen saver in the > kernel... The simple answer for this is to run in a kproc, and set the priority to "idle", so it only runs when there is nothing else to run. 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 2) Inability to disable the screen saver in, for example, a "panic" situation, where there is no opportunity to return to user space and have the screen put back into a known good state. This is analogous to the problem we have diagnosing kernel panics while X11 is running on the console: only the user space program can undo what it has done, and we can not run the user space program. > Some peopel want to write "interesting" screen savers... Now we see the real reason for this... 8^). > >Now if you could run Windows screen saver modules, you > >might have a good argument for change, above and beyond > >"change for the sake of change". > > Personally I am not interested in fancy screen savers :-) But, just want > to keep things tidy and keep the system running smoothly. By moving > much of the screen saver support from the console driver to the > user-land... The problem here is that only the video driver knows what it knows; short of converting FreeBSD's console over to something like "GGI", you will have a hard time moving *everything* to userland. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
> 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, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
>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 restructuring in various parts of syscons. 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 :-) >You can use kldload or the loader with the -t 'foo' stuff to load configuratio >n >files, etc. that modules can get at. Um, I know the loader can load arbitrary files in the kernel space with its '-t' option (the splash screen actually uses it to load a bitmap). But, can kldload do similar thing? It donesn't look it can... Kazu >Just pointing out that userland is not the only way of achieving your goals. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
>> 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 in your screen saver(s). Both points/complaints/requests have been raised several times in our mailing lists in the past. (Sorry, I don't keep copies.) Some people don't like cputime eaten up by the screen saver in the kernel... Some peopel want to write "interesting" screen savers... >Now if you could run Windows screen saver modules, you >might have a good argument for change, above and beyond >"change for the sake of change". Personally I am not interested in fancy screen savers :-) But, just want to keep things tidy and keep the system running smoothly. By moving much of the screen saver support from the console driver to the user-land... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Death sentence to KLD screen savers? Comments?
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 > becomes idle. It should not spend long time to draw something > to the screen. But, we may be tempted to do a bit more elaborate > drawing so that we get "interesting" effects. It's too easy to > degrade the system performance by staying in the screen saver > too long. You can stick the screen saver in a low priority kthread and achieve the same effect. > - While it is easy to manipulate the video board in the KLD module > (because we can go anywhere and access anything :-), there are > limitations. If you want to perform file I/O (to obtain some > bitmaps from files), or want to read some sort of configuration > file, there is no straight forward way to do so. You can use kldload or the loader with the -t 'foo' stuff to load configuration files, etc. that modules can get at. Just pointing out that userland is not the only way of achieving your goals. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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" ... ] 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 in your screen saver(s). Now if you could run Windows screen saver modules, you might have a good argument for change, above and beyond "change for the sake of change". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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 -- Larry Baird| http://www.gnatbox.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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 does the occasioanal segfault - oops!) So, I've got some work in progress for the application part of this. Are there any plans on how the kernel might go about calling the userland side of this, any docs, need proposals etc ? Personally, I'm in favour, I *hate* the kld interface for screensavers! However, I'm still using 4.3, is there a huge difference with vgl/vesa in -current ? (I assume the userland end would want to use vgl ?) Oh one other thing, it would be nice if a screensaver could be linked to a syscons vty and vgl access could be done without root perms. Or something like that. I particularly like the idea that one could choose their own screensaver if they are logged in and the system can have a default of something else when the tty is waiting on getty. So, I am VERY interested in seeing this move forward and can test things, or perhaps code things, once I've reread the style guide! > I will publish sample implementation once VESA support in -CURRENT > stabilizes. I've got a sample vgl screensaver type app that does a similar thing to fire_saver.c, just not wrapped as a screensaver yet. (It does however use al available CPU right now =)) Steve Roome P.S. I'm not subscribed to this list, so please include me in any replies. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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 the console, it will launch a specified "screen saver > >> program." > > > >No "periodical checks" please. It must wait on poll/select or kqevent or > >something like, event based, event provided by syscons. > > Because there already is the CONS_IDLE ioctl, I thought it's > easy for the screen saver daemon to use this ioctl. But, if > kqevent is preferred, we can do that. Maybe I am not clear, but periodical checks is time/resources waste. Sleeping on event wait, swapped out is more preferred, not occupes memory, etc. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
>> 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 "periodical checks" please. It must wait on poll/select or kqevent or >something like, event based, event provided by syscons. Because there already is the CONS_IDLE ioctl, I thought it's easy for the screen saver daemon to use this ioctl. But, if kqevent is preferred, we can do that. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
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 > periodically checks if the console is idle. When it finds no > activity in the console, it will launch a specified "screen saver > program." No "periodical checks" please. It must wait on poll/select or kqevent or something like, event based, event provided by syscons. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
