multiple topics (Higher Half and LFB, VFS and HAL)

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
BASICFreak
Member
Member
Posts: 284
Joined: Fri Jan 16, 2009 8:34 pm
Location: Louisiana, USA

multiple topics (Higher Half and LFB, VFS and HAL)

Post by BASICFreak »

Ok, so I haven't wanted to ask any of these questions by them self so I decided to compile a list and ask all at once.

1) In a higher half kernel mapped at 0xC0000000 (actually 0xC0010000 - 0xC0020000 for kernel and modules), but I have LFB enabled which in my case starts at 0xC0000000 or 0xF8000000 depending on my test system in use. So I have to know if the LFB uses physical or virtual addresses to pull the data, I read that you can do a page flip buffer on the LFB, so it seems like it uses virtual addresses to me.

So the first question is, How would I setup a higher-half kernel over 3GB if the video buffer can be anywhere over 3GB? Or can I change the LFB location?



2) This is probably more of an opinion on design rather than facts. Currently my HAL is the only communication to the "outside" world (outside of CPU that is), and my VFS is a HAL device. The VFS keeps track of partitions (max 255) and file systems (again 255 max).
HAL and VFS Structures:

Code: Select all

	typedef struct PARTITION_STRUCT { //32Bytes
		uint8_t HALid;
		uint8_t Subid;
		uint8_t FSid;
		uint8_t flags;
		uint64_t PartOffset;
		uint64_t PartSize;
		char name[12];
	}__attribute__((packed)) Part_t, *Part_p;

	typedef struct FILE_STRUCT { //64Bytes
		Part_p Partition;
		uint32_t Current;
		uint32_t Position;
		uint32_t FileSize;
		uint8_t flags;
		char name[47];
	}__attribute__((packed)) FILE;
	typedef struct HAL_DEVICE	{ // 32Bytes per Entry
		void (*open)(void*, void*, void*, void*);
		void (*read)(void*, void*, void*, void*);
		void (*write)(void*, void*, void*, void*);
		void (*install)(void*, void*, void*, void*);
		void (*uninstall)(void*, void*, void*, void*);
		void (*close)(void*, void*, void*, void*);
		char name[8];
	}__attribute__((packed)) HAL_t, *HAL_p;
The file system table is HAL_t[256].
So the HAL is called with an open command for the VFS passing FILE* File and char* Path, from there it checks the partition for a file system, if the driver exists it passes *Path+3 to the file system to locate the file. The File System driver calls HAL_read/HAL_write for the HALid File->Partition->HALid with offset of File->Partition->PartOffset and Device id File->Partiton->Subid (for multiple drives controlled by one driver, such as up to 4 FDC's and 4 HDD's PATA)

I am currently debating of separating HAL and VFS as I've had it in my previous revision. Which would allow me to also have a Partition Read/Write function to avoid more hassle with the FS Drivers - which I could do with another HAL device, though it seems like too many layers - but I see this getting in the way if say I wanted to run a FS over UART or CAT5 or even if I wanted to be crazy Video Buffer.

So my second question, which is not really a question but asking for opinion, What would be YOUR recommendation for HAL and VFS?

I'm not looking for posix at all, in fact I want to avoid it as much as possible.


Thanks for your time, and hopefully that was all legible :D
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
Sortie wrote:
  • Don't play the role of an operating systems developer, be one.
  • Be truly afraid of undefined [behavior].
  • Your operating system should be itself, not fight what it is.
madanra
Member
Member
Posts: 149
Joined: Mon Sep 07, 2009 12:01 pm

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by madanra »

BASICFreak wrote:1) In a higher half kernel mapped at 0xC0000000 (actually 0xC0010000 - 0xC0020000 for kernel and modules), but I have LFB enabled which in my case starts at 0xC0000000 or 0xF8000000 depending on my test system in use. So I have to know if the LFB uses physical or virtual addresses to pull the data, I read that you can do a page flip buffer on the LFB, so it seems like it uses virtual addresses to me.

So the first question is, How would I setup a higher-half kernel over 3GB if the video buffer can be anywhere over 3GB? Or can I change the LFB location?
The LFB uses physical addresses, so you can map it wherever you want in virtual address space.
User avatar
BASICFreak
Member
Member
Posts: 284
Joined: Fri Jan 16, 2009 8:34 pm
Location: Louisiana, USA

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by BASICFreak »

madanra wrote:The LFB uses physical addresses, so you can map it wherever you want in virtual address space.
Thanks for that piece of information, I have to rewrite my memory management (with threads in mind this time) so I'll go ahead with putting the kernel in higher memory.

Anything to postpone writing another FAT driver... (I know FAT like the back of my hand now... and now I have to code it again :x , [bad idea] at this point I'm almost wanting to drop FAT and roll my own and not support anything else [/bad idea])
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
Sortie wrote:
  • Don't play the role of an operating systems developer, be one.
  • Be truly afraid of undefined [behavior].
  • Your operating system should be itself, not fight what it is.
madanra
Member
Member
Posts: 149
Joined: Mon Sep 07, 2009 12:01 pm

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by madanra »

BASICFreak wrote:
madanra wrote:Anything to postpone writing another FAT driver... (I know FAT like the back of my hand now... and now I have to code it again :x , [bad idea] at this point I'm almost wanting to drop FAT and roll my own and not support anything else [/bad idea])
You could go straight for ext2 :) There's a little more to it than FAT, but it's a more sensible design, so it's arguably easier.
User avatar
BASICFreak
Member
Member
Posts: 284
Joined: Fri Jan 16, 2009 8:34 pm
Location: Louisiana, USA

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by BASICFreak »

I took some time off after I got my memory management down, so this is a few days late...

madanra wrote:You could go straight for ext2 :) There's a little more to it than FAT, but it's a more sensible design, so it's arguably easier.
The issue will still remain, I have to make 3 FS drivers:
1. That will fit in less than 512 bytes to load stage two (so very minimal)
2. 16-BIT stage two loader (full readonly driver)
3. 32-BIT driver to fit into my VFS (at least this one is to be written in C)


Oh, I also decided to place my HAL and VFS inside the kernel and have them as separate entities (VFS requires HAL but is not accessed through the HAL). The reasoning behind doing so was simplicity, I want to use the VFS inside the kernel to load the rest of the system so I did not want to have to search through running modules and have a hackish way of doing so. The Hardware and File System Drivers are still separate from the kernel and loaded currently as BOOT Time Modules.
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
Sortie wrote:
  • Don't play the role of an operating systems developer, be one.
  • Be truly afraid of undefined [behavior].
  • Your operating system should be itself, not fight what it is.
User avatar
Rusky
Member
Member
Posts: 792
Joined: Wed Jan 06, 2010 7:07 pm

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by Rusky »

You could get rid of the many-filesystems problem by using UEFI, or at least get rid of the MBR's file system by storing stage 2 in the free space between the first sector and the first partition.
User avatar
BASICFreak
Member
Member
Posts: 284
Joined: Fri Jan 16, 2009 8:34 pm
Location: Louisiana, USA

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by BASICFreak »

Rusky wrote:You could get rid of the many-filesystems problem by using UEFI, or at least get rid of the MBR's file system by storing stage 2 in the free space between the first sector and the first partition.
I wish I could use UEFI my test system is from 1998 (AMD A5) [Heck even my Dev system doesn't have UEFI, 2008]

And unfortunately I am currently booting with 1.44M FD and placing stage two in reserved space makes the disk unreadable (at least in windows haven't tried on linux)


Note:
I'm only using floppy until my drivers for the HDD are in place again, then I will use the floppy to install to HDD.
This is the third time I scrapped all my code in the last year :D But I have learned way more this time, I even understand ASM and the CPU way better due to the bootloader - Grub does not do what I wanted so I had to get rid of it.

Other than BIOS my test system is fully under my control :lol:
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
Sortie wrote:
  • Don't play the role of an operating systems developer, be one.
  • Be truly afraid of undefined [behavior].
  • Your operating system should be itself, not fight what it is.
User avatar
Rusky
Member
Member
Posts: 792
Joined: Wed Jan 06, 2010 7:07 pm

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by Rusky »

You might still be able to switch the BIOS on your test system if coreboot supports its motherboard. You can definitely get UEFI on QEMU using TianoCore OVMF.
User avatar
BASICFreak
Member
Member
Posts: 284
Joined: Fri Jan 16, 2009 8:34 pm
Location: Louisiana, USA

Re: multiple topics (Higher Half and LFB, VFS and HAL)

Post by BASICFreak »

Rusky wrote:You might still be able to switch the BIOS on your test system if coreboot supports its motherboard. You can definitely get UEFI on QEMU using TianoCore OVMF.
I can guarantee they do not support my motherboard (on the test system that is) as the BIOS ROMs are just that ROM Modules (maybe PROM but not EPROM), I can physically remove the BIOS (not that I have or would, but I could)

Other than that great test system...
Whole 233MHz 32MB ram (don't even remember the type it was before the PC100/133 SDRAM)
3.5" and 5.25" FDD and a single 64GB HDD (no optical drive)
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
Sortie wrote:
  • Don't play the role of an operating systems developer, be one.
  • Be truly afraid of undefined [behavior].
  • Your operating system should be itself, not fight what it is.
Post Reply