[FFmpeg-devel] libossupport status

[Michael Niedermayer]

On Sat, Dec 22, 2007 at 10:18:41PM +0100, Vadim Lebedev wrote:
> 
> 
> Michael Niedermayer wrote:
> 
> >On Sat, Dec 22, 2007 at 08:06:51PM +0100, Vadim Lebedev wrote:
> >  
> >
> >>Luca Abeni wrote:
> >>
> >>    
> >>
> >>>Hi all,
> >>>
> >>>int the last weeks, I've been silent about libossupport, but I continued
> >>>to work on it. Here is a report about the current status of things.
> >>>
> >>>First of all, the requirements:
> >>>1) Eliminate all the OS-dependent code from libav* (this can be achieved
> >>>in small steps)
> >>>2) For standard (POSIX?) systems, no dependency on libossupport should
> >>>be created
> >>>3) libav* code should use standard (POSIX?) functions, and the
> >>>implementation of such functions for non-standard systems should be
> >>>provided by libossupport
> >>>4) It seems that most of the developeres do not want libossupport in
> >>>ffmpeg, but want it as an external library.
> >>>
> >>>Did I understand the requirements correctly? Am I forgetting anything?
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>I wonder how do you intend to implement missing POSIX functionality on 
> >>Win32 plaftorm
> >>    
> >>
> >
> >Theres no intention to implement it all, just what we need in ffmpeg.
> >
> >
> >  
> >
> >>For example on win32  close()  will not accepts socket handles  and 
> >>select()  will not work on file handles, meaning
> >>    
> >>
> >
> >If win32 supports closing sockets, there should be a function doing that,
> >that can then be used. If it supports the equivalent of select() on files
> >AND we need that, then the existing function can be used.
> >If win32 doesnt support XYZ and we do have a implementation for it currently,
> >that can be moved from libavformat to libossupport. If we win32 doesnt
> >support XYZ and we do not have a implementation for it there wont be one
> >on libossupport either. At least not until some win32 devel implements it.
> >
> >  
> >
> I'm affraid i was not clear enough:
> 
> Suppose that ffmpeg (or one of components) use 'close(fd)'   to close 
> file decriptors and sockets.
> On WIN32 it means that ossupport will have to imlement 'close' routine 
> which takes a pseudo fd determinine if it relates to file descriptor
> or socket descriptor and do esear call to 'original_close(realfd[fd])'  
> or closesocket(realdsocket[fd]).
> Now in order for this to work we need we need to implement our owne 
> version of 'open' and 'socket' APIs.
> And of course most of the syscalls which accepts file decritptors.
> 
> This will pose 2 problems: 
> 1) Sheer amouht of work
> 2) public symbol clash. 
>     It will be difficutl to have our  'close' function which will be 
> called 'close' by the way to call original 'close' for C runtime library
> 
> 
> The current approach with "#include "os_support.h"  avoid all these problems

Let me try again, libossupport is a place to move the CURRENTLY EXISTING os
support code to. And whenever possible to clean it up in the process.

For close() there are 2 possibilities.
1. if the used file/socket descriptors are unique relative to each other
   on windows then calling close(some socket) will fail -> closesocket()
   can be tried this is 2 lines of code
2. if the used file/socket descriptors are not unique relative to each other
   on windows, that is close(5) and closesocket(5) both succeed and do
   something else then we can just do:

source in libav*:
#include "libossupport/os_support.h"
..
loss_nonstd_closesocket(socket);

libossupport/os_support.h:
#if HAVE_CLOSESOCKET but not CLOSE
#   define loss_nonstd_closesocket closesocket
#else
#   define loss_nonstd_closesocket close
#endif

This also does not add any dependancy on libossupport at link nor runtime.
Not even for windows.

If possible we should use POSIX and emulate that in libossupport. If this is
not possible then non standard functions/macros can be added to libossupport
with names making their non standard-ness clear. This ideally should be done
so that no link/runtime dependency is added.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071222/195c3470/attachment.pgp>