From owner-freebsd-current@freebsd.org Tue Sep 12 06:17:21 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96FA2E1B4AC for ; Tue, 12 Sep 2017 06:17:21 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.161.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CFF963525; Tue, 12 Sep 2017 06:17:20 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f182.google.com with SMTP id s62so26211014ywg.0; Mon, 11 Sep 2017 23:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=C5TmmrCQm1U6yOzH0emn34LFMoQkyFXlImnKq4ZzTGM=; b=EAY7OqSPZPu34RhrLHOsxuPXkGajFQE11F8M1F3nuLcRIiozx4Op19mkHAF9NoTayR qeIDRFtEDKbj9m9joJal0AHo+r7PUtM0sUOg1MbwPv6reuzQNRg/ywlmt+v/hCFVKPoQ q3Uu0gagh13W3K6xYycMxTKLkuRdGKlADKPQzydw+2cz3vaMWLDyZj/jOolF6Yz4PU7N Ndzh85X+7w1UU9ObyLYYuNMjqU3rptDnTuq4a8EPlyW936wuJmLHPMtQYp5aCfOWAToM V6+P1+SOAeB6kH60mzIpyiVC2BY6n52IaGUMSaFWO3Mt9BXUXcDm/AbGU9113EqGAezj S0YA== X-Gm-Message-State: AHPjjUg+rLrHmEqFPIXekRihbZLz2hwTz4DxRnmbSH42Y9iUqBfohZHq IgYoLbGfM7AeO1pekr0= X-Received: by 10.129.48.1 with SMTP id w1mr12665869yww.146.1505197034343; Mon, 11 Sep 2017 23:17:14 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id b201sm3650590ywe.20.2017.09.11.23.17.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 23:17:14 -0700 (PDT) Received: by mail-io0-f177.google.com with SMTP id v36so27510999ioi.1; Mon, 11 Sep 2017 23:17:13 -0700 (PDT) X-Google-Smtp-Source: ADKCNb6CFDXeNCrqSmbNM6OfWJXuy8VjDmsPIrjjCNJbF2k4/uaGuKuVD3Lf02OBnGWdiWlqOhOcQ1g+yj8xSTOm3DQ= X-Received: by 10.107.11.102 with SMTP id v99mr9082657ioi.260.1505197033396; Mon, 11 Sep 2017 23:17:13 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.81.131 with HTTP; Mon, 11 Sep 2017 23:17:12 -0700 (PDT) In-Reply-To: <8d04540b-6daf-aa13-5648-0ec2541cbae6@freebsd.org> References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> <8d04540b-6daf-aa13-5648-0ec2541cbae6@freebsd.org> From: Conrad Meyer Date: Mon, 11 Sep 2017 23:17:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: extending the maximum filename length To: Julian Elischer Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 06:17:21 -0000 On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer wrote: > maybe we could get it into -current. > It'd be silly to have to have people re-inventing hte wheel all the time. > How about you put those changes into the reviews.freebsd.org and we can get > some general consensus on them. > We'll have to do similar for the Asian customers and anyone who uses UTF-8. > So it > would be silly to have to develop it all again (but subtly different of > course). > > The key issue is how many system calls and other APIs would be broken, > and how many would be broken in a non backwards compatible way? > > We would need it in a stable/10 and 11 branch but if the patch is isolated > enough we could carry it forward until we get to 12. > > One has to allow people to do whatever they are used to with Windows. > And in this case the issue is serving files over samba to windows machines. Hey Julian, I've thrown the patch up at https://reviews.freebsd.org/D12330 . I haven't actually tested it on FreeBSD, but it does compile. We also have some patches against contrib/pjdfstest to fix those tests against long file names, but I think we can hold off on those changes until we've nailed down what the architectural change will be (if any). It's quite possible this accidentally breaks even more APIs than expected and we should do some fine tuning to reduce the damage. Our $WORK product mostly doesn't care about ABI, so we may not have noticed some ABI breakage. If anyone else is interested, please subscribe or add yourself as a reviewer on the phabricator revision. Best, Conrad