OSDev.org

dozniak wrote:So, are you content with using

Code: Select all

::

or you will have to instantiate TTY just to satisfy your whim desire to use

Code: Select all

.

?

That is a tough one! The dot is so much more satisfying. I absolutely adore it.

A this point I think you need to consider just how many things in the kernel itself actually needs to use a virtual TTY at all - mind you, I am aware that you were just using that as an example, but I suspect it is relevant in general.

Sticking to the console for the nonce, just what do you expect will need a virtual TTY? The only driver that should have access to the console is the console driver itself. The same applies to the disk drivers. You might want a logging operation for those and other drivers, but whether two or more share a single log would depend on several factors, and a TTY interface is probably no the best choice anyway (enough of the logging operations are shared that it would make more sense to let the logger do most of the text generation, and give the processes using the logger a more structured interface than a simple stream). As I already said, the userland console handling would need a separate API simply by dint of having to cross the system call boundary.

So that leaves the question, just what are you expecting to have to share all these things? I think you'll find that a lot of the things you are expecting to need them are things which should be touching them in the first place.