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
