Re: POSIX XXXat() methods
Brian Inglis <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Organization | Systematic Software |
| Message-ID | <[email protected]> |
On 2020-07-20 16:33, Joel Sherrill wrote: > Eshan has been looking for generic implementations of the 15 POSIX methods > like openat(), mkdirat(), etc. He has searched the normal places I know of > and hasn't found implementations of most of them that don't just call a > dedicated system call. Here is his analysis. > > https://docs.google.com/spreadsheets/d/1nEniQOs9TxDy5fb7P0_XFg7VknQDldG1BDFWSoqdKg0/edit?usp=sharing > > It appears that many could be implemented generically but with possible > overhead of saving current working directory, changing, returning, etc. and > likely race conditions. > > Does anyone have any ideas on where to get generic implementations to port? > Or implementation strategies to write OS agnostic versions? Would those used by Cygwin in the other half of your favourite repo qualify, although AFAIK they are under LGPL3+ with a section 4 Combined Works Linking Exception and section 5 Combined Libraries allows choice of terms with conditions: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/CYGWIN_LICENSE https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/COPYING.LIB Add openat, faccessat, fchmodat, fchownat, fstatat, futimesat, linkat, mkdirat, mkfifoat, mknodat, readlinkat, renameat, symlinkat, unlinkat to list of implemented Solaris functions. https://sourceware.org/git/?p=newlib-cygwin.git;a=blobdiff;f=winsup/cygwin/syscalls.cc;h=1a2572186c320c15275f458a8dad7623e09d40b7;hp=28533a58b961e2e379a6bda3904e7ecfa072cf75;hb=c57b57e5c43ab112e50d5e214b8cef61f8027946;hpb=ca48eb65e9f332484b1fe00ae373a1121091cbfb and check around that time and search the logs for others; POSIX compat xref in: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/doc/posix.xml;h=8e88245acc0f6e1de10c8fecd81be6e1529dd0a2;hb=HEAD readable: https://cygwin.com/cygwin-api/ -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]