On Sun, Dec 16, 2012, Vincent Torri wrote:
> On Sun, Dec 16, 2012 at 11:33 AM, Carsten Haitzler <ras...@rasterman.com> 
> wrote:
> > On Sun, 16 Dec 2012 10:54:24 +0100 Maxime Villard <rusty...@gmx.fr> said:
> >
> >> Hi,
> >> == efl/src/modules/ecore_evas/engines/buffer/ecore_evas_extn.c ==
> >> OpenBSD doesn't have shm_open(), just shmget(). As ecore_evas_extn.c
> >> doesn't seem to be used, I commented all the file and it works, but
> >> it would be better if someone adds #elif HAVE_SHMGET or replaces
> >> shm_open() by shmget(), which is standardized. I don't know these
> >> things.
> >>
> >> Thanks
> >
> > i'ts used by elementary. we will be doing more of this shm_open... because 
> > it's
> > frankly immensely more useful than sysv shm.
> >
> > 1. you have a NAME to share things by... easy to have a common known name
> > 2. evas cserve2 is built on it and cserve2 will becomes required - no 
> > choice.
> > 3. shm_open etc. uses fd's and mmap. unlike sysvshm.. u can resize a shm
> > segment by just munmap+mmap or mremap(). sysvshm in linxu has some 
> > EXTENSIONS
> > to do this, but its non-standard...
> >
> > so you won't be able to avoid shm_open for a lot longer... so i suggest,
> > instead of "just disable it for bsd", you find an acceptable solution... 
> > maybe
> > pressure open/free/whatever bsd kernel devs to support it. we probably need 
> > to
> > move this api/abstraction into eina - BUT... at some point those os's that 
> > dont
> > provide something as feasible/usable/nice as above are going to have a bad
> > day. :)
> 
> then annonce *clearly* that you support only POSIX systems, that is,
> you don't suport anymore Windows, BSD (and Mac) and Solaris, hence it
> remains only linux.

I see things a bit differently: we know that windows mac and solaris
won't change easily. The BSDs (I've never considered Mac OS X as a BSD
system btw) can change. That function is POSIX.1-2001 and most of the
BSDs boast themselves as sticking to standards. This is something they
should _want_ to have and I don't understand why they don't.

Are there bug tracker entries for that issue or any explanation why this
function is not available?

With that said, considering that it will take a new OS release for such
functions to become available and that it'll take time for people to
upgrade, it's clear there will be an issue when this code is released.

The portability issue with cserve2 has already been mentionned a few
months ago and there was no solution that fit everyone's needs. The EFLs
are working rather well nowadays overall and such things are comfort
compared to platform support (yes, I'm thinking of Windows here). Does
the lack of cserve2 (or others) prevents making applications? And if it
does, maybe that most people are willing to trade that functionality bit
for better platform support.

I agree SysV IPC is really annoying but at some point, adding all the
time more stuff that works on linux but not elsewhere gives way too much
work for the few people who do the porting. It makes the porting effort
a continuous unrewarding sprint.

GTK has issues with Windows, Qt's support in the future doesn't seem
terribly good to me. It's always the same story and it'd be a shame for
the EFLs to take the same path instead of taking advantage of a better
support when the other toolkits are getting worse.

-- 
Adrien Nader

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to