From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulrich Drepper Subject: Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers Date: Thu, 27 Aug 2009 10:24:28 -0700 Message-ID: <4A96C14C.8040105@redhat.com> References: <1250697884-22288-1-git-send-email-jack@suse.cz> <20090820221221.GA14440@infradead.org> <20090821114010.GG12579@kernel.dk> <20090821135403.GA6208@shareable.org> <20090821142635.GB30617@infradead.org> <20090821152459.GC6929@shareable.org> <20090821174525.GA28861@infradead.org> <20090822005006.GA22530@shareable.org> <20090824023422.GA775@infradead.org> <20090827143459.GB31453@shareable.org> <20090827171044.GA5427@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jamie Lokier , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16473 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbZH0RYk (ORCPT ); Thu, 27 Aug 2009 13:24:40 -0400 In-Reply-To: <20090827171044.GA5427@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 08/27/2009 10:10 AM, Christoph Hellwig wrote: > The question is how to handle this at the libc level. Currently glib= c > defines O_DSYNC to be O_SYNC. We would need to update glibc to pass > through O_DSYNC for newer kernels and make sure it falls back to O_SY= NC > for olders. I'm not sure how feasible this is, but maybe Ulrich has > some better ideas. The problem with O_* extensions is that the syscall doesn't fail if the= =20 flag is not handled. This is a problem in the open implementation whic= h=20 can only be fixed with a new syscall. Why cannot just go on and say we interpret O_SYNC like O_SYNC and=20 O_SYNC|O_DSYNC like O_DSYNC. The POSIX spec explicitly requires that=20 the latter handled like O_SYNC. We could handle it by allocating two bits, only one is handled in the=20 kernel. If the O_DSYNC definition for userlevel would be different fro= m=20 the kernel definition then the kernel could interpret O_SYNC|O_DSYNC=20 like O_DSYNC. The libc would then have to translate the userlevel=20 O_DSYNC into the kernel O_DSYNC. If the libc is too old for the kernel= =20 and the application, the userlevel flag would be passed to the kernel=20 and nothing bad happens. The cleaner alternative is to have a sys_newopen which checks for=20 unknown flags and fails in that case. --=20 =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro S= t =E2=9E=A7 Mountain View, CA =E2=9D=96 -- 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