Hi Jiri, > Forwarding to the list... > > -------- Forwarded Message -------- > Subject: Re: Why was support for real console on Ultra removed? > Date: Tue, 21 Nov 2017 23:48:24 +0100 (CET) > From: Jiri Svoboda <[email protected]> > To: Jakub Jermář <[email protected]> > > Jakub wrote: > > Yes, this was intentional. I removed this legacy initialization code in > favor of a DDF based one which uses serial console and can be used > together with ever-improving QEMU w/ OpenBIOS* (but broke keyboard > support on the real Sun workstations for the time being) even by people > who don't have access to a real-world Sun workstation. > I see, but technically these should not be mutually exclusive, right? > Input server
I don't remember the details, but somehow it stood in the way. Maybe it is the same ns16550 device and so there was a conflict... > I intend this regression in functionality to be rather temporary as it > should be possible to reimplement the lost functionality using DDF > drivers. We should however first discuss how to figure out which device > is the console. The boot argument solution is a bit clumsy and > inflexible. > > I guess for "real" serial ports (that have sockets on the chassis) we > want a configuration utility that allows you to select what's connected > (since reliable auto detection is probably not possible). For that we already use the boot argument. > For a fixed > function port such as the Ultra keyboard port, you'd want the system to > automatically do the right thing. I don't know if there is any generic > way to detect such a port (OpenFirmware properties?) or if you'd > actually need to specify which device is the keyboard for each > particular model. In any case it's a rather complicated problem so I > wouldn't hold my breath. There is a way to figure this out from the OFW tree. But then there is a problem to figure out the correspondence between the OFW tree nodes and the DDF device nodes. And then there is a question of who should attempt to find the correspondence. Certainly not the uart driver. Maybe the platform driver? After its entire subtree is built? Or should the platform driver simply use some kind of regex to rewrite the OFW path into our location service path? Even before its subtree is fully initialized? Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
