On Tue, 18 Dec 2012 01:14:10 +0100 Vincent Torri <vincent.to...@gmail.com> said:
> On Tue, Dec 18, 2012 at 12:50 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Tue, 18 Dec 2012 00:15:25 +0100 Vincent Torri <vincent.to...@gmail.com> > > said: > > > >> On Mon, Dec 17, 2012 at 5:14 PM, Maxime Villard <rusty...@gmx.fr> wrote: > >> > Le 17/12/2012 01:10, Carsten Haitzler (The Rasterman) a écrit : > >> >> 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. :) > >> > > >> > So, excepted me, nobody uses and feels concerned by BSD's ? > >> > >> they don't care about other OSs. They work exclusively on linux and > >> don't even try to think about other OSs. It implies that a port for > > > > that's total bullshit. utterly. we think. we simply make decisions that > > doing development and improving efl - using api's specified in posix for a > > long time > > and the port of the EFL on Windows has not starting last year... Since > you guys know that there is a Windows port, you have never asked me if > a new feature will be problematic or not, except for around one year. > I can give several examples... And that's not bullshit. do we have to ASK YOU every time we use an api call from a library? do we need your permission? does this mean we don't THINK about it or care because you have not become the arbiter of every api call we may or may not use? let me give you an example of me caring - evas_generic_loaders. from the VERY FIRST i supported dumb mmaped files in /tmp - AND shm_open... AND data down the pipe. i did this so there was an alternative to passing the data that was portable, with shm_open being the most preferred. since it was already assumed that performance here was not so critical.. it wasn't as important. what i didn't do is add al the checks for shm_open and so on as any checks i add would succeed always and i'd not be testing failure cases. also... the eina_file stuff for shm... happily implemented only half of it - the "open an existing one" case. it totally missed the "i might want to create one" case. and so shm_open is still prevalent in the code higher up and growing. to be honest - we dont really have enough use cases yet to nicely wrap all usage patterns - except at least one... the ability to create new ones. no ability to set permissioning or O_CREAT/O_EXCL/ORDONLY vs O_RDWR etc. no resizing (ftruncate ()). no ability when opening to indicate we want it to be shared etc. ... my point is that there is a whole bunch of complaining here with the "you forgot about my os". there is a perfectly good beginning of an api to wrap and solve it - it just isn't there currently in a stae that can be used, and that we're happily exploring the uses of shm first before baking all of it into an api we have to maintain going forward. none of us is going to ask permission to do that. first play, figure out what works, what we need,how we use it - do it in several places, then find the pattern and make it common. > Vincent > > > now is more important than STAGNATING and NOT doing development. i listed by > > sysvshm is far worse than shm_open already. > > > > i spent time actually reading up on these (apparently unlike you). we cant > > (portably - except with extensions.. only on linux .. resize sysvshm > > segments. shm_open can be easily implemented "dumbly" just with tmp files, > > but you lose the benefits of an explicit shm_open that says "hey - this is > > not really meant to be a file... it's shared memory - so many u dont want > > to allocate real disk nodes/blocks and sync any data to disk (unless you > > have to swap - then put it in swap as usual)"... i started using shm_open > > because it solves the "crap sysvshm" problem AND sets the right "hints to > > the os" for the shm file. > > > >> another OS than linux has to implement very bad hacks and a ton of > >> work, like i did for Windows, to try to *mimic* what is done with > >> linux. > > > > correct. like linux had to spend decades implementing hacks to mimic > > solaris, and ultrix and aix, and irix etc... now the tables turned. > > > >> Vincent > >> > >> ------------------------------------------------------------------------------ > >> 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 > > > -- ------------- 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
