From owner-freebsd-hackers Mon May 3 9: 1:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [207.244.223.187]) by hub.freebsd.org (Postfix) with ESMTP id 7B50715043 for ; Mon, 3 May 1999 09:01:15 -0700 (PDT) (envelope-from kbyanc@alcnet.com) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id MAA56249; Mon, 3 May 1999 12:12:50 -0400 (EDT) Date: Mon, 3 May 1999 12:12:50 -0400 (EDT) From: Kelly Yancey To: Dag-Erling Smorgrav Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: new loader question / module question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ~kbyanc@alcnet.com~ "Silly penguin, Linux is for kids" On 3 May 1999, Dag-Erling Smorgrav wrote: > Kelly Yancey 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