Hi Jaromir, Sorry for the delay. Unfortunately, even though the system returns EOPNOTSUPP for fallocate, the cross compilation stops with the error saying that the compiler cannot create executables since it couldn't write out the output file. As mentioned in my answer to Maciej, even when I return 0 to mock success in my linux fallocate syscall implementation, I get a segfault. But that I did not chase yet further.
Best regards, r0ller -------- Eredeti levél -------- Feladó: Jaromír Doleček < jaromir.dole...@gmail.com (Link -> mailto:jaromir.dole...@gmail.com) > Dátum: 2019 november 9 22:01:15 Tárgy: Re: adding linux syscall fallocate Címzett: r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) > R0ller, is your problem only that the linux binary used for cross-compile errors out, because of the system call returning ENOSYS rather than potentially expected EOPNOTSUPP? In that case the right fix is indeed to add the mapping into the compat code. Then the code would fail the way expected by the tool. Linux also doesn't support fallocate() universally, actually even when supported some of the filesystems return EOPNOTSUPP when e.g. unsupported flag combination is used. Jaromir Le mer. 6 nov. 2019 à 10:12, r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) > a écrit : Hi Maciej, Thanks for the detailed answer! Unfortunately, I don't think that I could accomplish this task in my spare time:( Please, don't take this as an offence but as a fix for my case I thought of an utter hack: I do know that writing a file by calling fallocate can be tricked and redirected into a named pipe of which the data can simply be pulled into a normal file. This is what I'm already doing in my project as a workaround when building it as 32bit arm lib: mkfifo mypipe cat mypipe > myfile <execute 32bit crosscompile via ndk> The problem with this is that it cannot be used when crosscompiling autoconf projects where a configure script starts creating many files as I'd need to edit the script at too many places to implement this trick. However, if I could carry out this trick with the pipe when intercepting the linux fallocate call, it could work. Do you think it feasible? Best regards, r0ller -------- Eredeti levél -------- Feladó: Maciej < maciej.grochow...@protonmail.com (Link -> mailto:maciej.grochow...@protonmail.com) ) > Dátum: 2019 november 4 23:32:56 Tárgy: Re: adding linux syscall fallocate Címzett: r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) ) > Hi r0ller, A couple of weeks ago I also run to the issue when I found lack of fallocate or POSIX_FALLOCATE(2) (to be precise) a little bit sad. >From the very first view typical usage of POSIX_FALLOCATE(2) seems straight >forward, comparing to the Linux fallocate(2) where different modes have to be >supported. However, things can go a little bit more complicated if you are >dealing with an existing file with a more complex structure. Because of that, I found difficult to provide good quality implementation without a proper way to test it. Before EuroBSD 2019 as a part of work about fuzzing the FFS, I decided to bring some well known FS test (namely speaking "XFS tests') suit to make sure that bugs that we fix did not introduce a regression. The same thing applies to the new features of FS, is relatively easy to port implementation from other OS/FS, but without a proper way to test them, I would be very careful to introduce such things too quickly to the end-users. One thing that I was missing for XFS tests, and going to publish part of it soon, is a way to view the internal structure of inodes and other metadata of Filesystem. My primary use case was to debug mount issues, in the example the issue that I showed during my presentation about the fuzzing. But also same apply to the code that manipulates inode blocks. Hopefully, we can elaborate on that, and as I pointed earlier I would be careful with merging new FS features especially such wide used as POSIX_FALLOCATE(2) without a proper FS test suit or extensive enough testing that would require proper too like i.e. FSDB. Thanks Maciej ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, November 3, 2019 6:06 PM, r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) > wrote: Hi Jaromir, Indeed. That's bad news but thanks for your answer! I've even found this: https://wiki.netbsd.org/projects/project/ffs-fallocate/ (Link -> https://wiki.netbsd.org/projects/project/ffs-fallocate/) Are there any details for this project besides that page? I don't know anything about NetBSD internals though if it's not meant for gurus, I'd have a look at it and give it a try. Best regards, r0ller -------- Eredeti levél -------- Feladó: Jaromír Doleček < jaromir.dole...@gmail.com (Link -> mailto:jaromir.dole...@gmail.com) ) > Dátum: 2019 november 3 15:16:34 Tárgy: Re: adding linux syscall fallocate Címzett: r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) ) > Le dim. 3 nov. 2019 à 08:57, r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) > a écrit : > As you can see on the attached screenshot, "line 4741" gets printed out. So I > went on to check what happens in VOP_FALLOCATE but it gets really internal > there. > > Does anyone have any hint? fallocate VOP is not implemented for FFS: > grep fallocate * ffs_vnops.c: { &vop_fallocate_desc, genfs_eopnotsupp }, /* fallocate */ ffs_vnops.c: { &vop_fallocate_desc, spec_fallocate }, /* fallocate */ ffs_vnops.c: { &vop_fallocate_desc, vn_fifo_bypass }, /* fallocate */ Jaromir
