<trungnt2910[m]>
<nielx[m]> "I guess it's more for the person..." <- Yeah, GitHub has an option to squash instead of merge commits from pull requests.
Ampilin has joined #haiku
<Ampilin>
buenas estimados, como estan?
Ampilito has joined #haiku
Ampilin has quit [Read error: Connection reset by peer]
<trungnt2910[m]>
Any reason why _kern_reserve_address_range is kept private?
<Ampilito>
disculpen ya volvi nuevamente
<Ampilito>
estare por aqui un rato mas si alguien quiere conversar
<jessicah>
trungnt2910[m]: like many things, there probably hasn't been a need
<jessicah>
and adding a libroot counterpart just wasn't done, or is called via some other POSIX api
<jessicah>
ah, looks like just used internally
<jessicah>
so just one of those things where there hasn't been a need to make a public api in libroot
<jessicah>
you could probably just include the private header explicitly, if you need to?
Ampilito has quit [Quit: Vision[]: i've been blurred!]
<pairisto[m]>
I was able to add tun to the build/jam/images/definitions/minimum file under the SYSTEM_NETWORK_DEVICES variable, and after running ifconfig tun (or tun0) create I get ifconfig: Could not add interface: Address family not supported by protocol family and I think I need to add it to SYSTEM_NETWORK_DATALINK_PROTOCOLS in the same file but I do not know how it links to the tun interface?
<trungnt2910[m]>
<jessicah> "you could probably just include..." <- Private headers are messy.
<jessicah>
Does mmap do something similar?
<trungnt2910[m]>
No...
<trungnt2910[m]>
But I probably can use B_OVERCOMMITTING_AREA with create_area instead.
<trungnt2910[m]>
.NET seems to want to reserve a big fat chunk of memory. Then it wants to create some memory regions on it.
<trungnt2910[m]>
After that, each memory region are cloned into two modes: read-write or read-execute.
<trungnt2910[m]>
They're currently implementing it with a shared memory file, but Haiku doesn't seem to support them.
<trungnt2910[m]>
Instead, Haiku attempts to actually create that gigantic file on disk.
<trungnt2910[m]>
I therefore am looking at supporting this by using Haiku's area APIs, probably marking anything in this chunk of memory B_CLONEABLE_AREA.
<jessicah>
I'm pretty sure x512[m] did work to improve shmfs
<trungnt2910[m]>
Before implementing this though I want to do some more research on cloned areas.
<trungnt2910[m]>
jessicah: It's not mounted by default so...
<augiedoggie>
ramfs gets mounted by default
<trungnt2910[m]>
Is it mounted to somewhere specific?
<trungnt2910[m]>
Somewhere that I can hardcode and expect it to be stable across Haiku released.
<augiedoggie>
/boot/system/var/shared_memory
<augiedoggie>
i believe it's planned to keep it at that location
<augiedoggie>
but i'm not the person to ask about that
<trungnt2910[m]>
Also, I need a file that's 256GB. Does ramfs support lazy physical memory allocation.
Maturi0n_ has joined #haiku
<augiedoggie>
i'm going to assume yes, because `dd` just let me create a 512GB sparse file
<waddlesplash>
ramfs does support lazy, yes
<waddlesplash>
however it's not very sophisticated about it
<waddlesplash>
you can exahust system RAM this way and it will not happen very nicely
<waddlesplash>
trungnt2910[m]: just use mmap ANON with MAP_NORESERVE
Maturi0n has quit [Ping timeout: 480 seconds]
<waddlesplash>
then mprotect in whatever yo uactually need
<waddlesplash>
we can/should extend madvise to actually allocate memory when told to, and let it return ENOMEM gracefully
<trungnt2910[m]>
Is there any way to mmap and get a `B_CLONEABLE_AREA`?
<waddlesplash>
set_area_protection
<waddlesplash>
mmap just creates areas, change protection after creation
<x512[m]>
trungnt2910: There are special area exists for marking reserved virtual memory.
<trungnt2910[m]>
<waddlesplash> "mmap just creates areas, change..." <- Hmmm, well then, any way to clone a range of areas?
<trungnt2910[m]>
Also, what happens when set_area_protection is called for a range that covers only a part of an area? Will it be split?
<waddlesplash>
you can't
<waddlesplash>
set_area_protection changes an entire area
<waddlesplash>
trungnt2910[m]: no, just clone one at a time?
<waddlesplash>
why do you need to clone anything though?
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
<HaikuUser>
hello
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
mmu_man has quit [Ping timeout: 480 seconds]
Ampilin has joined #haiku
<trungnt2910[m]>
<waddlesplash> "set_area_protection changes an..." <- Ahh wait, I was thinking of another API.
Ampilin has quit []
Ampilin has joined #haiku
<trungnt2910[m]>
It was set_memory_protection.
<Ampilin>
hello
<trungnt2910[m]>
<waddlesplash> "why do you need to clone..." <- .NET wants to do something strange with its memory: It wants to map the same physical page twice in its address space, one with a protection of RW, the other with RX protection.
<zdykstra>
Hi Ampilin
<waddlesplash>
trungnt2910[m]: you don't need B_CLONEABLE_AREA set to clone your own areas
<trungnt2910[m]>
<waddlesplash> "why do you need to clone..." <- On most UNIXes except Apple, .NET is using it using a memory-mapped file. That file is created on a RAM-backed filesystem and has a size of 256GB.
<waddlesplash>
setting it allows *other* processes to clone the area
<trungnt2910[m]>
waddlesplash: Ahh that's nice.
<waddlesplash>
why not use the Apple codepaths?
<trungnt2910[m]>
* that's nice (but that reveals a bug in my HyClone implementation).
<trungnt2910[m]>
waddlesplash: Because Apple uses its own platform-specific API to achieve the same thing.
<waddlesplash>
I think that fact is utilized in mediakit somewhere
<waddlesplash>
ok
<waddlesplash>
well anyway, yeah, you can just mmap and then clone_area, no need for a file-backing
<trungnt2910[m]>
So the "correct" way to do it on Haiku is to just loop `get_next_area_info` and then `clone_area`?
<waddlesplash>
no
<waddlesplash>
area_for(ptr)
<trungnt2910[m]>
I want a range though.
<waddlesplash>
just check area_for(ptr+size)==area_for(ptr)
<waddlesplash>
really that should always be the case based on what it sounds like your usecase is
<trungnt2910[m]>
What happens when you mmap a big area, munmap something in the middle (creating a hole), and then mmap the same range again. Will it become 3 areas?
<waddlesplash>
yes
<waddlesplash>
that will cause the area to be "cut"
<waddlesplash>
if you really want to be safe I guess you can use get_area_info(area_for(ptr), ...
<trungnt2910[m]>
waddlesplash: But the problem is the range might not cover one area.
<waddlesplash>
iterating over all areas will be slow if you have thousands of them, let the kernel do a binary tree lookup
<waddlesplash>
trungnt2910[m]: so check it, like I'm suggesting?
<nekobot>
[haiku/haiku] d9642c25bb28 - headers/os: Bump max gcc to 13.x
<trungnt2910[m]>
PulkoMandy was suggesting that the new `TIOCM_RNG` definition should be defined in Haiku as a "BSD extension", but I'm trying to make my point that _none_ of the existing TIO*** constants are actually POSIX and therefore `TIOCM_RNG` should not be treated specially (either keep it along with the other constants, or move them all to `_DEFAULT_SOURCE`/a BSD header/whatever.
<trungnt2910[m]>
* PulkoMandy was suggesting that the new `TIOCM_RNG` definition should be defined in Haiku as a "BSD extension", but I'm trying to make my point that _none_ of the existing TIO\*\*\* constants are actually POSIX and therefore `TIOCM_RNG` should not be treated specially (either keep it along with the other constants, or move them all to `_DEFAULT_SOURCE`/a BSD header/whatever).
<trungnt2910[m]>
nekobot: Ahhh nice.
<trungnt2910[m]>
How often are Haiku buildtools updated? Seems like we're still using something from two years ago.
<trungnt2910[m]>
Ahh no, what I meant was a version bump.
<trungnt2910[m]>
So when will Haiku stop using GCC 11?
<zard>
Do you mean why is the version available from HaikuDepot behind the latest version?
<Skipp_OSX>
whenever Jérôme Duval gets around to it
<trungnt2910[m]>
<zard> "Do you mean why is the version..." <- Yeah something like that.
<trungnt2910[m]>
Latest version widely used is 12.x, some Linux distros offer 13.x, while Haiku still uses 11.3
<Skipp_OSX>
but apparently we've already confirmed that the ABI is ok up to gcc13 at least on 64-bit
<Skipp_OSX>
so we are clear to upgrade gcc to version 13 when we want to do that
<Skipp_OSX>
but somebody has to do the work ... so ... we're on 11.3 for now
<trungnt2910[m]>
Yeah it doesn't really matter unless you use some C++20 features.
<Skipp_OSX>
I think your TIOCM_RI change is ok but that's not really my area
<Skipp_OSX>
It seems like Pulko and Jessicah want those constant definition moved somewhere common, doesn't need to be a BSD extension
<Skipp_OSX>
but, personally, yeah I'd simply throw the constant it in the termio file
<trungnt2910[m]>
> They can be kept in the same file (it's a lot easier to understand this way), but should be guarded by _BSD_SOURCE or _DEFAULT_SOURCE so that the POSIX header does not accidentally define more things than specified in POSIX.
<trungnt2910[m]>
Quoting PulkoMandy.
<Skipp_OSX>
yeah makes sense
<trungnt2910[m]>
Problem is, this header is already defining things outside of POSIX.
<trungnt2910[m]>
So I'm suggesting either keeping my patch as-is or moving/guarding everything.
<Skipp_OSX>
I think guard everything is the idea
<Skipp_OSX>
but I have no idea what the effect of that would be
<waddlesplash>
trungnt2910[m]: also for your implementation additions you will also need to implement them in the generic tty layer
<waddlesplash>
the drivers/tty is the "legacy" tty system
<waddlesplash>
this should really be replaced with the generic one too but I think last time PulkoMandy looked at that there were some remaining differences he wasn't sure about
<PulkoMandy>
waddlesplash, I think they are identical now? There were some changes in the "generic" one that I had to revert because they were simpler but broken
<PulkoMandy>
the only difference now is that one is a driver and the other is a module
<Skipp_OSX>
but BeOS R5 did define TCGETA in termios.h
<waddlesplash>
PulkoMandy: iirc there were still one or two differences listed in your last commit message?
<waddlesplash>
but if not then we should indeed consolidate
<PulkoMandy>
the driver should remain, but it should be renamed pty instead of tty since that's what it does, and it should use the generic layer instead of being mostly a copy of it
<PulkoMandy>
the remaining difference is that the driver has a fixed number of ptys always allocated, the generic module allocates them on-demand
<PulkoMandy>
pty is a special type of tty that's used for Terminal and other terminal emulators, that do serial-like things but are in fact not associated with an actual serial port
<trungnt2910[m]>
I'm quite confused, a lot of `ioctl` values currently in `posix/termios.h` are not specified in POSIX, but they're not specified by any UNIXes either, so it can't be called a "BSD extension"
<trungnt2910[m]>
For example, TCWAITEVENT.
<waddlesplash>
yes, that's a BeOS extension
tuaris has joined #haiku
<PulkoMandy>
interesting, so where do we put these?
<trungnt2910[m]>
Just keep all of them where they are right now?
<PulkoMandy>
do we need a _BEOS_SOURCES in features.h?
<waddlesplash>
probably, disable these only in "strict" mode?
<PulkoMandy>
well it's a bit silly to move the BSD things out to be POSIX compliant, but then leave the BeOS custom things in
<waddlesplash>
you list 2 differences here
<waddlesplash>
PulkoMandy: well, I mean we don't disable functions like "readv_pos"...
mmu_man has quit [Ping timeout: 480 seconds]
<PulkoMandy>
yes, I know we don't do anything about that yet, hence the question, what should we do? :)
<waddlesplash>
leave it be, probably
<trungnt2910[m]>
Urhhhh.... So much debate surrounding a patch that involves one #define....
<waddlesplash>
or, maybe just for this, check when "strict" mode is enabled
<PulkoMandy>
trungnt2910[m], OS development is hard, especially if we try to do things the right way :)
<PulkoMandy>
but the conclusion for today can be that we have no solution yet for the BeOS things, and we can put that in a trac ticket to look into later
<PulkoMandy>
and you can leave them where they are for now
<trungnt2910[m]>
So just let it be (I've resolved your comments about duplicate #defines).
<trungnt2910[m]>
s/#/`#/, s//`/, s/./?/
<waddlesplash>
PulkoMandy: anyway, what about the two comments in your commit -- background r/w and separate settings?
<PulkoMandy>
well, as mentionned in my commit message, I have no idea what they do or if they are useful
<waddlesplash>
if these are not a problem anymore, then let's reimplement pty indeed
<waddlesplash>
ah
<waddlesplash>
well, I can probably figure that out
<PulkoMandy>
for the settings one, I think the two copies of the settings were kept in sync, but I'm not sure if that's always the case
<PulkoMandy>
in a PTY it may be possible for both sides of the communication (Terminal and the app running in it) to both change settings independently, but I don't know if that happens and if there is always a sync between the two
<PulkoMandy>
the background read/write, I don't know what that is
<waddlesplash>
hm it appears there are also ioctls implemented by one but not the other
<waddlesplash>
hmm, do we not set that by default already?
<waddlesplash>
I mean unset that, in drivers/tty
<waddlesplash>
I see reset_termios sets ECHO in c_lflag
<waddlesplash>
drivers/tty/tty.cpp line 760
<PulkoMandy>
I don't know what's the default and I also don't know what both Terminal and bash may change
<waddlesplash>
well clearly something is different!
<waddlesplash>
the generic TTY default looks to be the same as drivers/tty
<PulkoMandy>
I guess you can us tcgetattr (probably through 'stty -a' is the easiest way) to see if anything is different
<waddlesplash>
looks identical vs. old
<PulkoMandy>
so, settings at the bash side are identical. In the old driver we had two settings structure, with the other one at the Terminal side IIRC
<waddlesplash>
no, in the old driver we have one
<waddlesplash>
in the generic driver we have two
<PulkoMandy>
ok
<waddlesplash>
I think that's actually wrong?
<waddlesplash>
it clearly doesn't make any sense to have two window sizes, one on master and one on slave
<waddlesplash>
the other settings are related to process group, etc. (but the generic TTY layer mostly does not use these)
<waddlesplash>
then there's termios. does it make sense to have two termios, one for each side?
<PulkoMandy>
yes, I think it was done that way in the attempt to simplify the locking? which I had to revert because the simplified locking didn't work
<waddlesplash>
right
<PulkoMandy>
(caused deadlocks and kernel panics for serial ports)
<waddlesplash>
so, let's consolidate this
<waddlesplash>
PulkoMandy: also, a fun side effect of this refactor will be that you will be able to make any TTY, including from serial ports, a process' controlling TTY
<PulkoMandy>
but I don't know, because there is no history for the generic one, it is imported in one commit with a lot of changes from the old one already, and no explanation for why things were changed
<waddlesplash>
right
<waddlesplash>
well, you already consolidated the locks, so, lets' consolidate the settings too
<PulkoMandy>
yes, finally we can have a getty or similar and run shells on serial ports like it's 1970 :D
hightower2 has joined #haiku
<PulkoMandy>
yes, if that's the only reason the settings were duplicated
<PulkoMandy>
I guess I'll have to do the testing with real serial ports?
<x512[m]>
PulkoMandy: Running shell on physical serial port can be useful on various boards.
<PulkoMandy>
yes, I know, I use it frequently at work for Linux things
zard has quit [Quit: leaving]
Diver has joined #haiku
<waddlesplash>
PulkoMandy: actually, where are the settings copied at all?
<waddlesplash>
I don't see that happening
CPYou has joined #haiku
<PulkoMandy>
I don't know, I don't know if they are supposed to be identical or if there is a reason to have (some) settings be set differently on each side
<waddlesplash>
well considering the TTY driver has them always be the same on each side, let's go with that for now
<waddlesplash>
since that's what actually powers Terminal et al
<waddlesplash>
if that's not quite correct it's gone unnoticed so far
<PulkoMandy>
I need to remember how the locking works in this thing to review this
<waddlesplash>
there's one lock for a master and all child TTYs
<waddlesplash>
the settings follows the lock
<waddlesplash>
that's all, it's a very straightforward change
<waddlesplash>
you can see this happen in tty_create line 1276/1278
<PulkoMandy>
there's no way the master can be deleted before the slave?
<PulkoMandy>
(that would leave the slave with a pointer to deleted memory)
<waddlesplash>
no, then we'd have an invalid lock pointer
<waddlesplash>
this is already what happens
<waddlesplash>
before this commit there's just the 1 lock pointer to the master, now we have 2: lock, settings
<PulkoMandy>
I think your last commit is missing the deletion of the old tty driver?
<waddlesplash>
I didn't want to make the commit unreasonably large
<waddlesplash>
I can do that in the same commit, yes
<PulkoMandy>
deleted files don't count towards commit size? are there more thanges than that?
<waddlesplash>
pretty sure they do?
<waddlesplash>
you'll just see xxx thousand lines deleted
<PulkoMandy>
well they do in Gerrit/Git, but not for reviewing
<waddlesplash>
ok
<waddlesplash>
PulkoMandy: if you think this all looks good, I'll just add one more commit on the end for the deletion and merge
<PulkoMandy>
other than that it looks OK I think, would be nice to test with a real serial port to make sure it's working fine. Too bad I got rid of my Minitel a few weeks ago, I could have used it as a serial terminal
<waddlesplash>
hopefully OscarL will show up at some point and let us know if it works or not :)
<PulkoMandy>
(I have other ways to test but that would have made a fun picture. oh well)
<waddlesplash>
the only thing that could break a real serial port is the settings structure combination
<x512[m]>
> two halves of a TTY
<waddlesplash>
and I sincerely doubt it will, because I think the old architecture didn't make sense
<x512[m]>
> The original TTY driver
<x512[m]>
What is that original TTY driver?
<waddlesplash>
drivers/tty
<waddlesplash>
the thing that's getting replaced here
KapiX has quit [Quit: KapiX]
<x512[m]>
Why need a replace?
<waddlesplash>
because we have two TTY implementations?
<waddlesplash>
this unifies them
<PulkoMandy>
drivers/tty and generic/tty had almost the same code with some unnecessary differences
<PulkoMandy>
now everyone (both Terminal and real serial ports) use generic/tty
<PulkoMandy>
the new driver/pty handles the "special" things needed for Terminal
<x512[m]>
Why two TTY implementations? How old is this state?
<waddlesplash>
many years
<x512[m]>
2005?
<waddlesplash>
13 years apparently
<waddlesplash>
2010
mmu_man has quit [Ping timeout: 480 seconds]
<PulkoMandy>
initially we had only drivers/tty for Terminal, generic/tty was added for serial ports, initially as a copy of drivers/tty with "future plans" to merge them, which never happened
<waddlesplash>
well it's happening now :)
<PulkoMandy>
then people started changing one or the other for 10 years without keeping them in sync
<PulkoMandy>
so I had to review the code on each side to make them identical again
<nekobot>
[haiku/haiku] 0c2a5bb5ea94 - Replace the "tty" driver with a "pty" driver.
<nekobot>
[haiku/haiku] bbb4db92761f - Delete the old TTY driver.
<PulkoMandy>
and port fixes in either direction
<PulkoMandy>
no need to do this anymore, cool :)
<waddlesplash>
presuming I didn't miss anything in the cross-merge anyway :)
<PulkoMandy>
well I'll put testing serial ports in my TODO list
<waddlesplash>
the background read support plus controlling terminal setup was the last thing missing from generic, so the 3rd commit there adds it
<x512[m]>
Does it fix weird glitches in Terminal in RISC-V minimum build?
<waddlesplash>
I doubt it
<x512[m]>
I have strange trouble that line get duplicated on Terminal window resize. Backspace also work incorrectly.
<PulkoMandy>
I have some microcontrollers flashing to do "soon" (2 or 3 weeks until I receive the PCBs) so I'll test then if I don't get to testing it before
<PulkoMandy>
Terminal itself could do with a rewrite. I had started something based on libvterm for SerialConnect, but people keep adding a lot of new features to Terminal and I'm not sure if libvterm can do all these things
<nekobot>
[haiku/haiku] 9875f74d6567 - kernel/arm/paging: fix alignment issue in InterruptGetPageTableAt
<x512[m]>
Also why separate SerialConnect application is needed? Why not use Terminal?
<x512[m]>
Nobody made/ported serial client for command line yet?
<waddlesplash>
there's out-of-band control operations that SerialConnect supports
<x512[m]>
SerialConnect seems not support selection and copy/paste.
<PulkoMandy>
Not yet
<PulkoMandy>
But it supports setting baudrate and flow control from nice menus
OscarL has joined #haiku
<x512[m]>
Maybe it is possible to share terminal view by SerialConnect and Terminal?
<OscarL>
weee! only one tty now :-) ( too bad it still doesn't supports TCWAITEVENT, as needed by BSerialPort::WaitForInput() :-P )
<PulkoMandy>
That was the plan. But the one in Terminal is very complicated and badly written so I started a new one
<PulkoMandy>
When the new one is ready it can be used in Terminal too (and any other app that needs a terminal view)
* OscarL
will do some serial port checks with his mice again.
<x512[m]>
Serial mouse?
<OscarL>
yup!
<OscarL>
We had at least one user needing to use one a few months back.
jmairboeck has quit [Quit: Konversation terminated!]
FreeFull has joined #haiku
<waddlesplash>
PulkoMandy: is it really that badly written?
<waddlesplash>
OscarL: we should get rid of TCWAITEVENT entirely
<waddlesplash>
and the other unimplemented BeOS calls
<OscarL>
I assume BSerialPort::WaitForInput() should/could be implemented using something like select() ? (I think I've tried that months ago, but I just suck at programming :-D)
<Skipp_OSX>
I see now, no but pine is gonna come out with a riscv board "in June" that I could swap in there
<Skipp_OSX>
quotation marks are for previous riscv release claims
<Skipp_OSX>
beaglev
<OscarL>
waddlesplash: used your BSeriaPort code changes on a test app (that tries to read serial mice ids). This is on beta4. With your changes at least I get "1" as a count of available bytes to read, or "Operation timed out" (seems to respect different timeouts too).
<waddlesplash>
OscarL: so it works? :)
<OscarL>
still getting weird behaviour when using BSerialPort vs similar code that uses pyserial... but at least your WaitForInput() change seems fine :-)
<waddlesplash>
:)
<OscarL>
(still need to check the tty changes... will have to setup a nightly to test those, of course)
Ampilin has quit [Ping timeout: 480 seconds]
<x512[m]>
Where to put cache controller driver? add-ons/kernel/drivers/cache?
<x512[m]>
waddlesplash: What is the problem with implementing TCWAITEVENT? Good use case for condition variable.
<waddlesplash>
x512[m]: it's completely superseded by select
<waddlesplash>
it has no real usecase
<waddlesplash>
and there's already wait mechanisms inside the TTY layer.
<trungnt2910[m]>
<PulkoMandy> "it's not a driver, it's a module..." <- So it's some kind of kernel-mode "library" that is shared by the pty driver and some other ones?
<trungnt2910[m]>
The real "drivers" would handle the `open` syscall on their own devices right?
<x512[m]>
Not all drivers expose devfs nodes. Some drivers implements kernel interfaces. For example PCI host controller driver.
<nekobot>
[haiku/haiku] 071ff801eebd - BSerialPort: Implement WaitForInput() using wait_for_objects.
<waddlesplash>
trungnt2910[m]: yes, probably.
<trungnt2910[m]>
waddlesplash: So we should return a `status_t` and pass a pointer to a pointer as an output parameter instead, right?
<trungnt2910[m]>
Wouldn't that break public API?
<waddlesplash>
yes. and yes, but this is an internal driver
<waddlesplash>
we can break API, it's not "public"
<waddlesplash>
trungnt2910[m]: is it really worth it to try and implement this right now though?
<waddlesplash>
also I think your logic is incomplete
<waddlesplash>
we probably should reject TIOCEXCL if the TTY is already opened by more than one thing
<waddlesplash>
and actually allow opening it if nothing has opened it yet...
<waddlesplash>
also what's the master/slave interaction here?
<trungnt2910[m]>
waddlesplash: When nothing is opening the `tty` `is_exclusive` is always `false`.
<waddlesplash>
ok I guess this does look like the BSD impl
<trungnt2910[m]>
Really, since I haven't read it, not a single line.
<waddlesplash>
well ... again, if it's not really important, why work on this?
<waddlesplash>
there are probably bigger things to work on for .net besides little stuff :-p
<trungnt2910[m]>
waddlesplash: It does seem simple and I don't think it affects the main project as the time waiting to clear administrative stuff to get .NET PRs merged in is really long.
<trungnt2910[m]>
waddlesplash: I guess implementing popular APIs has the long-term effect of reducing the amount of work to port code in the future.
<trungnt2910[m]>
And also reduce the amount of platform-specific #ifdefs that .NET has to bear.