On Sun, 16 Dec 2012 21:15:58 +0100 Adrien Nader <adr...@notk.org> said:
> 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. my point here is.. it's going to be a requirement for evas to run no matter what... so cserve2 or bust. we have too many ifefs. too many codepaths. we wee it day in and out with people compalining "this is broken" and devs going "works for me" "can't reproduce"... and in so many cases... the bug is simply a lacking feature where efl adapted to some missing os features or missing libraries etc. - it becomes a time sink and makes for a poor experience of efl or e. so we're raising the bar and reducing the amount of "Delta" you can have. this also can reduce the amount of bugs. > 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. the reasons are many but here are some: 1. devs are almost all on linux... so guess what? they support the os they work on. 2. frankly linux has much more momentum than the bsd's (excluding osx as you say) and that lead as i see is only increasing. 3. the only other really "relevant" platforms are probably osx and windows. both of these can be dealt with. yes i know about psl1ght and many other more niche users. evil is there to fill in gaps for windows. it can provide shm _open by opening a file on disk and mmaping it like it already does. if there is an ability to force a file in windows to never be flushed to disk unless memory pressure would force it to be swapped out to the pagefile - then this is effectively the same behaviour... except it survivies a reboot. for osx - if there is a tmpfs that lives in ram, an shm_open can be provided that redirects to there. i don't know if there is - no osx. 4. for decades linux users have been at the bad end of the stick with people simply saying "well be posix compliant! make your own drivers" we won't support you!"... the tables are turning. slowly - in bits and pieces. and most linux users/devs are of the mindset of "we had to support oursevles for years... and so we did. time you did the same". :) the issues on the most part can be solved. the problem is that for the vast number of the core devs.. it's not THEIR issue (with some exceptions - yes vincent... :) i know :)). ecore-extn was optionally compileable before because i know it uses shm_open and so i made it an option. it also brought in ecore-con and ecore-ipc. these options are going away now though, so the problem is no longer going to be avoided. cserve2 - similar story. we've had cserve for years now and no one uses it - it was optional. cserve2 will become mandatory because it NEEDS to be tested and exercised en-masse. without something like cserve2 - we will bloat out badly if people write actual efl APPS. cserve2 is there to help contain that bloat before it begins. people are already writing efl apps, so it solves and existing problem anyway. the issues just need solving. in both the eore-extn code and in cserve2, the shm_open/mmap stuff is encapsulated and easy to replace etc. - it just has not been because of the above. the devs all have systems that have shm_open... so its not a priority for us and your todo lists are forever full. example. there is a case with ecore-extn where u can easly get a lock deadlock if you use it in a certain way. reality is people do use it that way and that problem is by far more important to me than shm_open stuff. :) > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
