From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Lieb Subject: Re: Re: Thoughts on credential switching Date: Tue, 22 Apr 2014 09:35:40 -0700 Message-ID: <3188256.8buApyBF7d@jlieb-e6410> References: <53565491.702@redhat.com> <53565D29.6010503@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Florian Weimer , Jeff Layton , Andy Lutomirski , "Eric W. Biederman" , LSM List , "Serge E. Hallyn" , Kees Cook , Linux FS Devel , "Theodore Ts'o" , "linux-kernel@vger.kernel.org" , To: Boaz Harrosh Return-path: Received: from natasha.panasas.com ([209.166.131.148]:46482 "EHLO natasha.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756642AbaDVQfy convert rfc822-to-8bit (ORCPT ); Tue, 22 Apr 2014 12:35:54 -0400 In-Reply-To: <53565D29.6010503@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tuesday, April 22, 2014 15:14:33 Boaz Harrosh wrote: > On 04/22/2014 02:37 PM, Florian Weimer wrote: > > On 03/27/2014 02:33 PM, Boaz Harrosh wrote: > >> POSIX or not it just does not have any real programming mining > >> at all. > >=20 > > What do you mean with "mining" in this context? >=20 > Sorry I saw this mistake after I posted. I meant "meaning". >=20 > What I'm saying is that the mess starts when you are trying > to keep patching a very wrong API. the POSIX politics aside, > in regard to user switching (and current directory and etc...) > this API is plain WRONG. I mean in the mathematical sense wrong. >=20 > All these application mess is not the application programmers > fault. He had to do what he had to do. The mess starts when you > are trying to keep a mathematical contradiction in your proof. >=20 > It is glibc mess for trying to maintain compatibility with > these "PROCESS WIDE OPERATIONS". And naming it holy names like > POSIX will not cover the mess that they are. As long as you try > to keep them there will be mess. If you want to honestly clean > things up is by throwing the true garbage out. Convert all legacy > code to new mathematically sound API's. >=20 > Peace > Boaz I don't want to keep this churning thread going. I'd rather solve toda= y's=20 problems. So let's put this in perspective and move on. Our project h= as a=20 problem to solve. I wouldn't necessarily say wrong, simply very out of date. All of thes= e=20 issues with POSIX and pthreads in particular come from one common sourc= e, the=20 actual capabilities of the systems, BSD, and SysV at the time. The goo= fy=20 localtime_r and friends were (and still are) hacks to work around the=20 simplistic interfaces in the original Bell Labs code that deeply assume= d a=20 single process with a single thread, i.e. there were only 3 segments, n= o=20 shared libraries or shared r/w memory and definitely no (real) TLS. Th= e=20 pthreads interfaces deeply assumed the same. Even worse, it had to als= o run=20 on VMS which (I don't believe) ever had kernel support for multiple use= r space=20 theads. ASTs are nasty enough and only worked because everybody knew t= hat you=20 were either in app code or the AST... So all of this stuff is based on= lowest=20 common denominator. The "Single UNIX Specification" was a peace treaty= among=20 warring computer companies out looking for lock-ins and competitive adv= antages=20 while reluctantly realizing that the ISV community (Oracle) really didn= 't care=20 about anything but a common base. Let's move on. Glibc has to keep some semblance of POSIX in order to c= ope=20 with legacy code from that era and I commend them for their perseveranc= e. But=20 that should not hold us back from leveraging today's architectures and,= more=20 importantly, today's multi-client workloads. If that means extensions = to=20 POSIX fine. But if POSIX gets hung up because *BSD doesn't have kernel= support=20 for thread level creds and *bsd.org doesn't want to do it, we just do w= hat fits=20 today's requirements and what Linux is capable of, Jim --=20 Jim Lieb Linux Systems Engineer Panasas Inc. "If ease of use was the only requirement, we would all be riding tricyc= les" - Douglas Engelbart 1925=E2=80=932013 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html