Messages in this thread |  | | | Date | Thu, 7 Mar 1996 21:59:19 -0500 (EST) | | From | Kenneth Albanowski <> | | Subject | Re: Blind-access patch for Linux 1.3.x |
| |
On Wed, 6 Mar 1996, Theodore Ts'o wrote:
> I'm the most uncomfortable with the changes to the bootsector. We only > have so many configuration bytes available, and using a full byte for > the blind option seems to not be the best use of that resource. > > Question: is it really critical that all of the hardware probe messages > always be accessible via the blind-mode console? How about this as a > proposal: > > All kernels will have support for turning on/off "blind mode" via the > escape sequences. Init will recognize the kernel command line argument > "blind=1", and if it sees it, it will send the escape sequence to all of > the console. A blind person who wishes to see the boot messages gets > Linux running using the above procedure, and then recompiles a kernel > whose default mode is "blind mode on". That will allow the blind person > to see the hardware probing boot messages. > > That simplifies the changes to the kernel, and hopefully it meets your > requirements. What do you think?
I've thought through the various permutations, believe me: yes, your idea works much better then most, but it requires a custom (or at least recent) init and it doesn't give any help if the boot locks up before getting to init.
I agree that using another bytes of the bootsector is disagreeable, but I don't see any other way of pulling the information from the vidmode setting, and that vidmode setting is by far the easiest thing to change in a kernel. (Indeed, I spent a long hard search trying to figure out why it wasn't being propegated through in the first place.)
For now, only a single bit of the flag in the boot sector is really being used. Perhaps the remaining 15 (sorry, but it was implemented as a word, not a byte) could be left open as additional flags?
Also, that patch only uses 0x1F0 on the i386. Other architectures (for good or for bad) haven't been touched.
I suppose a bit in the current screen_info structure could be used, if one can be spared somewhere. The highest bit of video_page, perhaps.
> - Ted
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
|  |