On 1/6/23 7:58 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
On Fri, 6 Jan 2023 at 18:22, Evgeny Iakovlev <eiakov...@linux.microsoft.com> wrote: > > > On 1/6/2023 17:28, Peter Maydell wrote: >> On Fri, 6 Jan 2023 at 15:44, Alex Bennée <alex.ben...@linaro.org> wrote: >>> Peter Maydell <peter.mayd...@linaro.org> writes: >> I think the theory when the semihosting API was originally designed >> decades ago was basically "when the guest does fopen(...) this >> should act like it does on the host". So as a bit of portable >> guest code you would say whether you wanted a binary or a text >> file, and the effect would be that if you were running on Windows >> and you output a text file then you'd get \r\n like the user >> probably expected, and if on Linux you get \n. > If SYS_OPEN is supposed to call fopen (i didn't actually know that..) > then it does make more sense for binary/text mode to be propagated from > guest. It's not required to literally call fopen(). It just has to give the specified semantics for when the guest passes it a mode integer, which is defined in terms of the ISO C fopen() string semantics for "r", "rb", "r+", "r+b", etc. > Qemu's implementation calls open(2) though, which is not correct > at all then. Well, as long as qemu does that, there is no > posix-compliant way to tell open(2) if it should use binary or text > mode, there is no notion of that as far as posix (and most > implementations) is concerned. QEMU doesn't have to be pure POSIX compliant: we know what our supported host platforms are and we can freely use extensions they provide. If we want to achieve the semantics that semihosting asks for then we can do that with open(), by passing O_BINARY when the mode integer from the guest corresponds to a string with "b" in it. I'm about 50:50 on whether we should do that vs documenting and commenting that we deliberately produce the same behaviour on all platforms by ignoring the 'b' flag, though. thanks -- PMM
Thanks Peter, i think i see your point. However, if you ask me, i feel like advertising a feature to guest code and only implementing it on 1 platform that supports it just because it has a non-standard POSIX implementation will only confuse the issue further. Guest code doesn't want to care whether or not an emulator is running on Linux or Windows, there is no notion of that leaking to guest code. What it cares about is being able to consistently use a certain feature in their code. So i think it would be rather useless to implement it on Windows-only given there is a clear alternative to switch to fopen. Just my 2 cents.
