From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757416AbaDVQgA (ORCPT ); Tue, 22 Apr 2014 12:36:00 -0400 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 From: Jim Lieb To: Boaz Harrosh 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" , Subject: Re: Re: Thoughts on credential switching Date: Tue, 22 Apr 2014 09:35:40 -0700 Message-ID: <3188256.8buApyBF7d@jlieb-e6410> Organization: Panasas Inc. User-Agent: KMail/4.11.5 (Linux/3.13.9-100.fc19.x86_64; KDE/4.11.5; x86_64; ; ) In-Reply-To: <53565D29.6010503@gmail.com> References: <53565491.702@redhat.com> <53565D29.6010503@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > > What do you mean with "mining" in this context? > > Sorry I saw this mistake after I posted. I meant "meaning". > > 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. > > 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. > > 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. > > Peace > Boaz I don't want to keep this churning thread going. I'd rather solve today's problems. So let's put this in perspective and move on. Our project has a problem to solve. I wouldn't necessarily say wrong, simply very out of date. All of these issues with POSIX and pthreads in particular come from one common source, the actual capabilities of the systems, BSD, and SysV at the time. The goofy localtime_r and friends were (and still are) hacks to work around the simplistic interfaces in the original Bell Labs code that deeply assumed a single process with a single thread, i.e. there were only 3 segments, no shared libraries or shared r/w memory and definitely no (real) TLS. The pthreads interfaces deeply assumed the same. Even worse, it had to also run on VMS which (I don't believe) ever had kernel support for multiple user space theads. ASTs are nasty enough and only worked because everybody knew that you were either in app code or the AST... So all of this stuff is based on lowest common denominator. The "Single UNIX Specification" was a peace treaty among warring computer companies out looking for lock-ins and competitive advantages while reluctantly realizing that the ISV community (Oracle) really didn't care about anything but a common base. Let's move on. Glibc has to keep some semblance of POSIX in order to cope with legacy code from that era and I commend them for their perseverance. But that should not hold us back from leveraging today's architectures and, more importantly, today's multi-client workloads. If that means extensions to POSIX fine. But if POSIX gets hung up because *BSD doesn't have kernel support for thread level creds and *bsd.org doesn't want to do it, we just do what fits today's requirements and what Linux is capable of, Jim -- Jim Lieb Linux Systems Engineer Panasas Inc. "If ease of use was the only requirement, we would all be riding tricycles" - Douglas Engelbart 1925–2013 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