That is a tough one! The dot is so much more satisfying. I absolutely adore it.dozniak wrote:So, are you content with usingor you will have to instantiate TTY just to satisfy your whim desire to useCode: Select all
::
?Code: Select all
.
C++ Handling Objects System Wide
Re: C++ Handling Objects System Wide
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
- Schol-R-LEA
- Member
- Posts: 1925
- Joined: Fri Oct 27, 2006 9:42 am
- Location: Athens, GA, USA
Re: C++ Handling Objects System Wide
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.
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.
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.