mikaku / Fiwix

A UNIX-like kernel for the i386 architecture
https://www.fiwix.org
Other
401 stars 32 forks source link

Support syscalls ftruncate64, stat64, lstat64, fstat64, and fcntl64. #50

Closed rick-masters closed 8 months ago

rick-masters commented 8 months ago

Closes #49

mikaku commented 8 months ago

Before checking the code in its own, I've seen some issues I'd like to discuss:

  1. (unsigned) long int must not be used on i386 code since is the same as (unsigned) int (4 bytes). We must try to avoid this type of data, otherwise the code could create confusion when adding support for a 64bit architecture.
  2. I don't see a correlation between https://git.musl-libc.org/cgit/musl/tree/arch/i386/bits/stat.h and the same file provided in the PR or even with the file in Linux 2.4 kernel (should I look at Linux 2.6?) . For instance, st_dev is defined as unsigned long long (8 bytes) in your PR but is defined as dev_t in musl which I presume is a 32bit field as in Linux 2.4.
  3. Why F_GETLK64, F_SETLK64 and F_SETLKW64 aren't declared as 12, 13 and 14 respectively as in Linux 2.4?
rick-masters commented 8 months ago

Before checking the code in its own, I've seen some issues I'd like to discuss:

  1. (unsigned) long int must not be used on i386 code since is the same as (unsigned) int (4 bytes). We must try to avoid this type of data, otherwise the code could create confusion when adding support for a 64bit architecture.

Can you suggest a type to use? Would __s32 be ok? If not, what type?

  1. I don't see a correlation between https://git.musl-libc.org/cgit/musl/tree/arch/i386/bits/stat.h and the same file provided in the PR or even with the file in Linux 2.4 kernel (should I look at Linux 2.6?) . For instance, st_dev is defined as unsigned long long (8 bytes) in your PR but is defined as dev_t in musl which I presume is a 32bit field as in Linux 2.4.

I believe the struture in the PR is consistent with musl. dev_t is a 64-bit field in musl. See line 31 here: https://git.musl-libc.org/cgit/musl/tree/include/alltypes.h.in

  1. Why F_GETLK64, F_SETLK64 and F_SETLKW64 aren't declared as 12, 13 and 14 respectively as in Linux 2.4?

I'll fix this, thanks. I copied the #define from musl but that doesn't work in Fiwix for confusing reasons. musl always forces the 64-bit syscalls (e.g. fcntl64) so the underlying F_GETLK is also forced to the 64-bit value (12) so the #define works in musl. But that doesn't work in Fiwix because it supports the 32-bit fcntl and so F_GETLK is not 12.

mikaku commented 8 months ago

Can you suggest a type to use? Would __s32 be ok? If not, what type?

For 32bit data types you can use (unsigned) int, not (unsigned) long int. I mean, we need to avoid using the word long when defining 32bit data types. We should rename those long by int since they are the same on an i386.

Also, data types should have complete names. I mean, not just unsigned, but unsigned int.

I believe the struture in the PR is consistent with musl. dev_t is a 64-bit field in musl. See line 31 here:

Oh, I see, forget it. I was just comparing it with the stat64 in https://elixir.bootlin.com/linux/2.4.31/source/include/asm-i386/stat.h. And those extra padding fields confused me.

The structure looks consistent indeed.

mikaku commented 8 months ago

I also see that the underlying truncate filesystem method in sys_ftruncate64() doesn't currently support 64bit offsets (__loff_t). I guess that's something I'll have to fix after merging this PR, otherwise this 64bit version will truncate at 32bit offset all the time.

rick-masters commented 8 months ago

I figured that limitation didn't matter because I thought the Fiwix filesystems were limited to 32-bit sizes anyway.

mikaku commented 8 months ago

I figured that limitation didn't matter because I thought the Fiwix filesystems were limited to 32-bit sizes anyway.

After including support for 64bit offsets into sys_llseek now I'm able to format ext2 filesystems up to 128GiB. Although I've not fully tested it.

mikaku commented 8 months ago

Thank you.

mikaku commented 8 months ago

I figured that limitation didn't matter because I thought the Fiwix filesystems were limited to 32-bit sizes anyway.

I've checked limits in Fiwix ext2 filesystems and I think (not fully tested) the file size is limited by i_size since Fiwix is not taking advantage of the field i_dir_acl as the higher 4 bytes of i_size (for files only, of course) as Linux 2.2 does.

So, although an ext2 file system can be as big as 128GiB, the maximum size for files will be 4GiB.