I am trying to figure out the data flow from writing to /dev/stdout to the character appearing on the console (screen). When Linux prints characters to a screen, does it use the BIOS INT 10h services? or does Linux implement it's own function to write characters to the screen without relying on the BIOS Interrupt services.
Further more, what happens when one is using the new UEFI booting? How do I go about not using the Legacy BIOS? Does not using the Legacy BIOS mean I should not depend on the BIOS interrupt services?
How is the /dev/stdout implemented?
Re: How is the /dev/stdout implemented?
First, /dev/stdout does not exists. It's merely a workaround to hide which terminal the app is using. If you enter the command "w" or "ps" you'll see the true tty names.
Second, when a character is written to that tty, it can be buffered (or not, depending on parameters), and send to the terminal daemon (part of the linux kernel blob), which interprets it (characters can form a control sequence as well) and finally pass it over to the video engine that displays the required glyph at given position.
Kernels do not rely on BIOS or UEFI to display a character. All has it's own implementation, and the firmware (BIOS or UEFI) is only used to determine the position and format of LFB in memory. New machines does not tend to have attrib+char buffers anyway, leaving only pixel framebuffers which means you'll have to draw glyphs on your own. The routines for doing this as well as the character/glyph bitmaps can be found in linux source, and also covered by our wiki.
About using UEFI only: our wiki has topics on that too. You can use the bloated official toolkit, or use assembly with a suitable assembler and include file (by that I mean fasm, and uefi.inc which can be found - what a surprise - in our wiki). Either way you'll need exactly the same services: get memory map, load a sector from disk etc. only this time you have to use EFI calls instead of BIOS ints. It's the bootloader's duty to put the gathered info in a well defined, firmware independent structure, this way a kernel does not need to know what kind of firmware it was booting from. Memory map is memory map regardless entries came from EFI GetMemoryMap call or from E820.
Second, when a character is written to that tty, it can be buffered (or not, depending on parameters), and send to the terminal daemon (part of the linux kernel blob), which interprets it (characters can form a control sequence as well) and finally pass it over to the video engine that displays the required glyph at given position.
Kernels do not rely on BIOS or UEFI to display a character. All has it's own implementation, and the firmware (BIOS or UEFI) is only used to determine the position and format of LFB in memory. New machines does not tend to have attrib+char buffers anyway, leaving only pixel framebuffers which means you'll have to draw glyphs on your own. The routines for doing this as well as the character/glyph bitmaps can be found in linux source, and also covered by our wiki.
About using UEFI only: our wiki has topics on that too. You can use the bloated official toolkit, or use assembly with a suitable assembler and include file (by that I mean fasm, and uefi.inc which can be found - what a surprise - in our wiki). Either way you'll need exactly the same services: get memory map, load a sector from disk etc. only this time you have to use EFI calls instead of BIOS ints. It's the bootloader's duty to put the gathered info in a well defined, firmware independent structure, this way a kernel does not need to know what kind of firmware it was booting from. Memory map is memory map regardless entries came from EFI GetMemoryMap call or from E820.