Date: Sun, 20 Oct 1996 11:00:57 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hackers@freebsd.org, sos@freebsd.org Subject: Re: splash-page on bootup.. Message-ID: <199610201500.LAA07973@skynet.ctr.columbia.edu> In-Reply-To: <199610201215.NAA13027@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 20, 96 01:15:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Luigi Rizzo had to walk into mine and say: [pardon the cascade here] > > > > > > If FreeBSD started putting up a splash page on boot I'd rip that = > > code > > > > > But the nice thing about the way Unixware does this is how easy it = > > is > > > > > to disable. Just rm or mv the logo file in /stand. > > > > > One vote for load a splash image if you find it in /stand otherwise > > > > I like this idea as well. Simple and easy, for all levels of expertis= > > e.. > > > > 2 votes! > > > Me too! Three! > > > > OK, I get the drift :) I'll look into doing it that way. It might be > > problematic to get at the filesystem sy early in the game though... > > Sorry if this has already been suggested (I did not read the initial > postings). > how about this: build a simple utility which allows the splash page (and > possibly its loader code, to be able to deal with different graphics > formats) to be appended/removed from /kernel: > > splashon kernel_file picture_file > splashoff kernel_file > > this way you don't need filesystem access, since the boot code is doing > that for you. > > Luigi If you ask me, the kernel shouldn't be responsible for generating a splash page at all. That's not what it's there for. Microsoft programmers may disagree with me, but these are the same people who came up with 'Bob,' so I'm not exactly inclined to listen to them. While I haven't actually used Unixware before, I'd bet a quarter that the reason they put the logo in /stand is that it isn't loaded by the kernel at all: it's probably loaded and displayed by the boot loader before the kernel is even touched. If I ruled the world and wanted to have FreeBSD display a startup logo, I would create a seperate bootable image that did just that and have the boot program load that instead of the kernel. Then, once the logo was dispalyed, I would have that image load the kernel. My rationale is this: the boot loader can switch in and out of protected mode so that it can access the BIOS. Well, you could take advantage of this to access the BIOS on graphics adapters too. (Bear in mind that I'm not an expert on PC graphics programming, but I vaguely remember reading somewhere that there are BIOS routines for manipulating the graphics display.) This would (hopefully) allow the logo displayer program to determine whether or not there's even a color graphics display available and, if there is, load the logo onto the screen in a nice simple fashion. Once that's done, it could load the kernel and go on with the show. If there is no graphics head at all (serial port console), the program could just display a text banner of some kind. If you want to skip the logo entirely, you can either specify a flag at the Boot: prompt, of you can just mv /logo out of the way so that the boot loader can't find it, at which point it will just load the kernel directly as is done now. There are a couple of downsides here: - The logo displayer image would need quite a bit of assembly language code to make it work. Well, hey: life sucks and then you die, okay? Deal with it. - While this approach will buy you a startup logo, it won't let you hide the autoconfig probe messages printed by kernel. (At least, I don't think it will: when the kernel initializes the console, it will probably force it back to text mode.) - When I tried to turn our second stage boot into a standalone image, I realized that the current boot program actually consumes much of the 64K alotted to it even though it contains such a small amount of actual code. The UFS filesystem groking code creates several large buffers which chew up a lot of the 64K segment. So even though you can take the boot program and make it into a standalone image that doesn't have to worry about the 7k file size limit anymore, I don't think it's possible to graft the logo displayer program onto it. (Last thing I attempted was to merge the biosboot and netboot programs together, but that didn't work since the two programs together wanted more data space than was available within the single 64K segment.) One possible way around this would be to keep the initial bootstrap image in memory and give the logo displayer program some way of jumping back to it. We could have it set a flag somewhere in memory that the bootstrap program could use to determine whether or not the logo has been displayed and skip displaying it the second time around. While this is not a simple project, it would undoubtedly make the computer gods very happy (avoiding kernel bloat is always a Good Thing (tm)). I'd personally give a medal to anyone who could pull this off. -Bill, "The Ed Wood of software" -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610201500.LAA07973>