Date: Thu, 19 Jan 95 9:40:02 MST From: terry@cs.weber.edu (Terry Lambert) To: wpaul@skynet.ctr.columbia.edu (Wankle Rotary Engine) Cc: freebsd-hackers@FreeBSD.org Subject: Re: More serial console stuff... Message-ID: <9501191640.AA07299@cs.weber.edu> In-Reply-To: <199501190654.BAA00363@skynet.ctr.columbia.edu> from "Wankle Rotary Engine" at Jan 19, 95 01:54:48 am
next in thread | previous in thread | raw e-mail | index | archive | help
> First, there's one thing I always do to the boot blocks when I do an > installation, which is to change the way 'unit' is calculated. Normally > it says this: > > part = unit = 0; > > This always forces unit 0 to be the default, which screws up autobooting > on my system because my root disk is unit 1 (wd1). The change I always > make is: > > part = 0; > unit = (drive & 0x7F); > > This automagically sets the unit to 0 or 1 accordingly. I've seen this > bandied about on the newsgroups, but I've often wondered why it never > became official. My guess is that this causes other problems that I'm > not aware of (which are undoubtedly related to SCSI disks, which I don't > have.) I'm tempted to sneak this in while I'm in the neighborhood, but > first I want to find out if this hack was already rejected for a reason. Actually, I've wondered about this very change. The other thing is that you can grab the part as well, although you have to hack 3 places for it. The size change is small (about +18 bytes). I'd also like to see the drive info for 0x80 and 0x81 passed from the bios. This is basically two function calls and stack pushes for each to do the deed in the second stage boot. This should be well under the size limitations, although it will interfere with MACH or NetBSD booting unless you hack it a little differently. To pass the extra data another way is, I think, 8 more bytes on top of that. Note that the function to be called already exists, you just need to do the anding later instead of sooner. Since it isn't already called many places, this shouldn't be an issue. The under 640k area, I am unsure about. In point of fact, you could obtain this information from the BIOS data area, if you had established a mapping. It's tempting to keep the lower 640k unadulterated for at least the first boot, until it can be copied off for use by a kernel based DOS emulator and a VM86() interface. You would want a copy in any case because of the possibility of crashing the emulator by a badly behaved program going off in the weeds, and the need to reset it. Another compelling reason is the ability to run multiple emulators and ultiple VM86() interfaces by putting them in seperate logical address spaces. The space is not actually wasted, since it's added back into the memory pool post-load. This does, however, push up the minimum boot size to 2M (I used to boot a stripped 386BSD kernel with no net in 640k just to point at it to annoy the UnixWare people who wouldn't let me do radical surgery on SVR4 to reduce it's memory requirements). There is some question as to whether or not you'd want to boot a kernel into the lower 640k if you could. Having a large portion of the kernel in loadable modules makes it more likely that you would want to do this, since it greatly increases the possibility of an initial image size of less than 640k. The load above 1M is a result of the initial contiguity requirements on the kernel image that spanned the 640k boundry. > Second, there are incidental problems involved with booting with a serial > port as a console. For one thing, you have to remember to edit /etc/ttys > properly before you bring the system up multi-user for the first time, or > you won't get a login prompt. Newbies aren't likely to be able to > figure this out, so I want to idiot-proof it for them. What I want to do > is change the default /etc/ttys, but I'm not sure exactly how to go > about it. I can either add another getty entry for 'ttyd0' or put a getty > on 'console'. Each of these options has its own problems. With a headless system, I think it makes sense to redirect the ttyv0 major/minor accesses to the serial port driver (and cause virtual consoles with getty's on them to be redirected to a hnging open that is interruptable with a signal, as if DCD were not present on a device the was configured for modem control). This neatly auto-enables the logins on the console and simultaneously takes care of the respwaning issues of a getty on a null device. I wouldn't mess with the console driver itself, in that case, since it is now unnecessary (it defaults to ttyv0 which points to your serial port). The console could still be redirected to an X console program on someone's X terminal. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501191640.AA07299>