Date: Thu, 29 Jan 1998 02:49:06 -0600 (CST) From: Joel Ray Holveck <joelh@gnu.org> To: mike@smith.net.au 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: <199801290849.CAA05120@detlev.UUCP> In-Reply-To: <199801290726.RAA02074@word.smith.net.au> (message from Mike Smith on Thu, 29 Jan 1998 17:56:58 %2B1030) References: <199801290726.RAA02074@word.smith.net.au>
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) Okay. Wouldn't a higher priority be to implement a userland VGA library that does these things? >> 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. Fine. I'll do the graphics primatives an easier way. >> 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. When I meant to load it from disk, I meant hold open a vnode, not actually page it in. That way, it comes from the pagable buffer space, rather than the wired vnode space. > 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) Hmmm... good point. And there's no way to guarantee that a given spl'd block of code will be paged in at any given time without great magic and pain. What about adding an splcons, as a subset of spltty? That should solve that issue, without breaking existing code. (Although this may traumatize serial consoles, I don't know.) > At this juncture, I would advise KISS. With the page fault issue, I would tend to agree. And believe me, at this juncture, I am finishing off a minimalist template. All these other things are ideas for future expansion. Remember, I'm not planning on doing this tonight. But when I finish this and the hacking bug starts nibbling at my fingertips again, then I'd like to have some idea of where to go. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801290849.CAA05120>