Reading files from ext2?

[sortie]

Writing an OS from start to finish doesn't mean you should do it in that order.

For instance, you can start with the kernel land and learn a lot and have a lot more fun, by skipping the bootloader phase by using GRUB. Later on when you are much more skilled, and when you know exactly why you don't like GRUB, you can make your own bootloader. This is the method I do, and I do intend to finish.

Do you actually want to finish your OS, when you say start to finish? Or do you just want to learn, have fun, and feel in control? You can get all that with a kernel.

[iansjack]

How do we know that known location?

That's an exercise for you to figure out.

I just want to make an OS from start to finish.

As the bootloader said to the OS, "Ceci n'est pas une OS".

I write all of my OS in assembly.

Your choice, but don't complain when it gets difficult.

Simply by design as I explained already.

Your explanation was that GRUB was for partitioned disks only. Not true. Invalid explanation.

Ok, I will try to understand the filesystem better, but I will not bother loading from a known location. It's just pointless.

Whatever you say.

That's almost right, actually they are 510 bytes.

Don't get smart with me, buddy. I've tried to be patient with you but I'm all out of patience now. So I'll leave you to it.

[glauxosdev]

I have written such a bootloader

Can I borrow some ideas from your bootloader? As I said I will not copy-paste it.

Do you actually want to finish your OS, when you say start to finish? Or do you just want to learn, have fun, and feel in control?

I want to learn, to have fun and to achieve something. I want also to control everything that will be in my OS, and so the bootloader.

That's an exercise for you to figure out.

No, that was a rhetorical question. I didn't either want to figure it out. I want to take the hard way.

Your explanation was that GRUB was for partitioned disks only. Not true. Invalid explanation.

The explanation is above in the same post. Sorry for being unclear. Also GRUB will be even heavier than my OS.

Regards,
glauxosdev

[iansjack]

In an ext2 partition, you have 1024 bytes for the bootloader, as the superblock doesn't start until 1024 bytes in. Of course, the MBR will probably only load the first 512 bytes, so you have to load the second 512 bytes yourself. Once you have 1024 bytes to play with, that is definitely enough to read a file from ext2; I have written such a bootloader, with pretty comprehensive error checking. That does require significant hand optimisation of the assembly to save space though. You can write it in considerably less space if you simply read inode 5 (reserved for a second-stage bootloader) rather than having to read the root directory and parse the directory structure.

I will not bother loading from a known location. It's just pointless.

[glauxosdev]

No, I meant to borrow only ideas, I will adapt them to my liking.

[madanra]

I have written such a bootloader

Can I borrow some ideas from your bootloader? As I said I will not copy-paste it.

You could do; but bear in mind the hand-optimization for space means the code is very difficult to read and follow. It is not the place to start if you're wanting to learn how ext2 works.

[glauxosdev]

@madanra: Don't worry, I have found several documents on ext2 (with the help of iansjack) and I know Assembly good enough to follow a bootloader. Actually it's easier for me to follow assembly code than C/C++ code.

Regards,
glauxosdev

[glauxosdev]

@iansjack, you were wrong. Madanra scans the root directory (inode 2). He said that I can also just read inode 5, but he didn't actually say he did that. Am I correct about the last statement?

[madanra]

I am planning to just read inode 5. I don't think that's any more a 'known location' than reading /boot.bin, like my old bootloader; I was interpreting 'known location' as the sector lists that GRUB sometimes uses, that are prone to breaking when you change the file in the filesystem. This is with the intention of then having sufficient space to in the future eg. use unreal/protected mode to load a larger payload, or implement ext4 support.

[iansjack]

I would say that inode 5 is a known location as it can be found with absolutely minimum knowledge of the filesystem; it's certainly far more "known" than /boot.bin which requires you to find inode 2, parse the root directory, find the inode of /boot.bin, and then find the appropriate blocks. By any reasoning that seems to be a significantly more complicated process than just finding the location of the blocks associated with a known, fixed inode.

But if it makes the pair of you happy to think otherwise, and thus deem my previous comments "wrong", then be my guest. I should worry!

[Marionumber1]

Hi,

Based on your advice and various documents, I wrote some code but it just doesn't load the kernel. I searched for sample ext2 bootsectors just to borrow some ideas, but I found nothing relevant. I have found bootsectors for fat12 and grub, which is for partitioned disks (if I am not mistaken). Edit: I was mistaken.
Could you point me to a ext2 bootsector? I promise, I will not copy-paste, I will just get some ideas.

Regards,
glauxosdev

I did write an EXT2 bootsector for my OS here. It can be loaded by an MBR or chainloaded by GRUB, though it actually just loads another flat binary loader, rather than the kernel itself. Whether or not it is possible to load a kernel in the 1024 bytes provided, you probably don't want to. There's a lot of preparatory work you should probably do, like getting a memory map and enabling paging for the kernel.

[glauxosdev]

Ok, I can now load the kernel with some ugly hacks. Then I found your code, Marionumber1. Thank you, although madanra already gave me his code.

I did write an EXT2 bootsector for my OS here. It can be loaded by an MBR or chainloaded by GRUB, though it actually just loads another flat binary loader, rather than the kernel itself. Whether or not it is possible to load a kernel in the 1024 bytes provided, you probably don't want to. There's a lot of preparatory work you should probably do, like getting a memory map and enabling paging for the kernel.

In those 1024 bytes except for ext2 kernel loading I change video mode, I get the ehci controller pci address, I open A20 and enable protected mode and I have still about 300 bytes free for those you suggested me and for other things.

Regards,
glauxosdev

[madanra]

I would say that inode 5 is a known location as it can be found with absolutely minimum knowledge of the filesystem; it's certainly far more "known" than /boot.bin which requires you to find inode 2, parse the root directory, find the inode of /boot.bin, and then find the appropriate blocks. By any reasoning that seems to be a significantly more complicated process than just finding the location of the blocks associated with a known, fixed inode.

But if it makes the pair of you happy to think otherwise, and thus deem my previous comments "wrong", then be my guest. I should worry!

Ah, sorry, I wasn't trying to argue with you! glauxosdev was keen to avoid a 'known location'; my intention was to suggest to them that loading inode 5 was an acceptable option, not to disagree with you.

In those 1024 bytes except for ext2 kernel loading I change video mode, I get the ehci controller pci address, I open A20 and enable protected mode and I have still about 300 bytes free for those you suggested me and for other things.

If you still have 300 bytes free, you are definitely missing out a lot of error checking.