Date: Thu, 29 Jan 1998 17:56:58 +1030 From: Mike Smith <mike@smith.net.au> To: joelh@gnu.org Cc: jonny@coppe.ufrj.br, jkh@time.cdrom.com, tlambert@primenet.com, dag-erli@ifi.uio.no, hackers@FreeBSD.ORG Subject: Re: Graphical screen saver Message-ID: <199801290726.RAA02074@word.smith.net.au> In-Reply-To: Your message of "Thu, 29 Jan 1998 01:13:27 MDT." <199801290713.BAA04624@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
> In my experience, the slightly higher-level graphics functions (line, > circle, etc) are rarely used, so I will probably write them but make > them optional linkage. I would be looking, instead, to the sort of primitives you find in modern graphics hardware (blit, filled polygon, etc). There's a reason that these are common. 8) > Is there any way to have ld, when linking the lkm, throw out all the > functions that aren't used, except the entry points that I specify? No. You could probably write something to digest an object and remove anything unreferenced, but this is fraught with danger. > I've considered this. So far, both of the graphic screen savers > written are very lightweight (2k, and daemon_saver is 6k), and are no > problem to load in the kernel. However, graphic programs are normally > large. The popular Bad Dog screensaver in AfterDark 3.0 is 536k, > which is far too large to link into the kernel. I am considering > writing a screensaver stub which loads an object file from disk and > calls routines in it. If you have "loaded it from disk", it is still in the kernel. If someone is mad enough to load a 600K screensaver, that's up to them. > (Would dlopen be the right interface, or does > the kernel have something better?) This allows the saver to be paged > out (since it's only in memory as a vnode, not an lkm), and makes for > slightly easier debugging. You might want to use this approach for data, but be aware that discussions recently have suggested that the saver be called at spltty(), and this may result in deadlock if the pages to be referenced cause a fault. (spltty() may block PPP/SLIP/PPBUS I/O which may be required to access the pages in question) At this juncture, I would advise KISS. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801290726.RAA02074>