Date: Mon, 3 May 1999 12:12:50 -0400 (EDT) From: Kelly Yancey <kbyanc@alcnet.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: new loader question / module question Message-ID: <Pine.BSF.4.05.9905031156030.53103-100000@kronos.alcnet.com> In-Reply-To: <xzpiuaa6v5f.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
~kbyanc@alcnet.com~ "Silly penguin, Linux is for kids" On 3 May 1999, Dag-Erling Smorgrav wrote: > Kelly Yancey <kbyanc@alcnet.com> writes: > > On 3 May 1999, Dag-Erling Smorgrav wrote: > > > Unfortunately, you're correct. What's more, the memory occupied by a > > > module is not reclaimed when the module is unloaded. > > Is there a way to free the memory allocated by the loader for the image? > > No. The image is a module as any other. So it should be possible to unload it right? I'm not at home right now so I can't try kldunload. If you can unload it, what happens if the user hits the saver key? > > > I'm thinking about providing a way to pass additional options to the > > splash module to enable/disable certain features (hence the idea in the > > original posting of using the loader to load a config file and then > > locating the tag and reading the configuration). > > What's wrong with sysctls? Where was my head :) Works for me. Maybe sysctl knobs under kern.splash? Really, where should they go? > > > > You don't have to use BMP files; you can use PCX files instead [...] > > Is this in -stable? or -current? My 3.1-19990309-STABLE machine only had > > a decoder for BMP files. > > Both. I MFCed the PCX decoder a week or two ago. > > > > A PNG decoder is also planned, but it's a lot more work than a PCX > > > decoder and I haven't found the time to finish it yet. > > Ouch...and I was starting to feel bad for investing any more kernel > > memory for something as trivial as a splash screen ;) > > What do you mean? The memory occupied by the decoder is > inconsequential (we're talking ten kilobytes on the outside). What > really eats up memory is the image, especially if you use a hi-res one > (my home box has a 1024x768 splash screen). PNG images have much > better compression than BMP or PCX, and will therefore occupy less > memory. Well, that was part of my point above...I'm trying to figure out a way to reduce the memory requirements of the image too. Really it was just a joke (hence the ;) ), but I have to admit it does at least seem odd to think we would funtionally have a PNG decoder in the kernel (albeit in a module), or even that we currently any picture decoder in the kernel...I would have laughed at the idea 10 years ago :) > > > Well, the first set of related patches (which I hope to have done by the > > end of the week) are to add some extra video modes to the syscons driver > > (320x400, 320x480, 360x200, 360x240, 360x400, and 360x480 modex). I'll > > post those to -hackers when I'm done. > > I don't think these are really interesting, since mode X is > interleaved, which makes for added complexity the decoder. It will > just add complexity for no real gain. Support for mode Q, on the other > hand, might be interesting for screen savers, and easy to implement. > 320x240 is currently in syscons and that is interleaved. And believe it or not...320x240 looks a lot nicer than 320x200. And not to hold Windows up as a shining example of the way things ought to be, but I'm almost positive their splash screen is actually 320x240 mode X. Really, I don't mind adding in the support in the splash module for the mode X resolutions. But the first thing I have to do is finish is adding support for them all to the syscons driver before I can use them. Thanks again, Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905031156030.53103-100000>