Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp16929649rwd; Mon, 26 Jun 2023 17:50:20 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ77D8+qCzmGfRwxlCHSECEzTEw+5c76L+kbls6+T1FY4f5xV9Byv3BY+6D5NC8Rv/GoOrMu X-Received: by 2002:adf:ec11:0:b0:313:fe14:1e31 with SMTP id x17-20020adfec11000000b00313fe141e31mr404425wrn.9.1687827019984; Mon, 26 Jun 2023 17:50:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687827019; cv=none; d=google.com; s=arc-20160816; b=W0hN2lIHHlgtNTSRF+fMgc0JwiY7/IDIr/DhUP5Nlmod4e0AA6J2uh5PMb5yWgxyjn YPPGAnTlY16TOYjDZ7w8ooYBU9OzOmtclfQSnnhLRAQ1DFgDQWkexgx2uaaKS5oXNVft Mmx2uXX1fDsjIy8vDVC0j7rm7BkC+6Ny+aXhXU4ydpq0xhptL5ki8jDo8OAAfH7ElRpB DHYjMYgbJo3xggDxTKxf446A6YVitAvXCKEHcYjmOG8mD/aKJulQw8Nla3R6yJuF5h7K svbGE8VvcqJj06f0uusi8kfM6wVrxwzD2jeR6WaeDPmf/yRRhmVczcnGnfX/XOnGGM8Q NuEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=86MSvmvVSt9S2UtHlwSRj79shZcJbZGSCsSZwTfwkJk=; fh=w+/sSBtLHC8uh4Bzv5sdjAKPf+ZkNJyt8g4kUw0fAVc=; b=PKZto+hqs/Xse9pNOe3BL1USMIoZJ1tZ3cCWOnO6eWn+jl+qv+jsNc0afqrMahBK3X uBSiFIrzR4kqJpLVl26z0jdkvmsPXXEgWwPBOQy9Svfrtg3e20o6l8+ThZcXqrQkmZwg 2DqWsee5vIwTQ7SWWsJff1d4fstmTnWR/0e0lsR9YfmrVM6Odk9fJKDUNG5I9qNwUTlt M7Ywj/NJHRwQgDAok6RgzKUg4Z9EcthH5xn/i1umxuEgEZ625Gq+pi/+mumhsdmjbMgY nfC6hW8FQdRvGjeG9GtCdObHzf78vg0aaRj8K88uFYzLs+gmrMXIFzkubL8/nntqQ7iU csqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@treblig.org header.s=bytemarkmx header.b=rdhQ3MKh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t3-20020aa7d703000000b0051a3911f66csi3368164edq.476.2023.06.26.17.49.55; Mon, 26 Jun 2023 17:50:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@treblig.org header.s=bytemarkmx header.b=rdhQ3MKh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229527AbjF0Ak3 (ORCPT + 99 others); Mon, 26 Jun 2023 20:40:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbjF0Ak2 (ORCPT ); Mon, 26 Jun 2023 20:40:28 -0400 Received: from mx.treblig.org (unknown [IPv6:2a00:1098:5b::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7E29AB; Mon, 26 Jun 2023 17:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org ; s=bytemarkmx; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=86MSvmvVSt9S2UtHlwSRj79shZcJbZGSCsSZwTfwkJk=; b=rdhQ3MKhSmA+Kq18olbUOmRVcx JTM83gTdGekmoSzFenUNRlAezwyw8Dsz7oYoCTN0hHNQhEB+DE0/Ghob/LZB1QsjxZYsGr6ocOtth Jz8qDxLjG0I6bv8pxYj5RS08uiYfI+EPWrjS4ic4ANLs5/lRc4Q9c7sfsYeq22UO7r4bJtW5kl5/V 94dgIwlgoXSAvwskV+QXDJajq3ZZmTnZ4qiJhyfvqKxaT8JUL79JgeKoLbLGqvtELjekL84nSZZ/O RmY5ibnDgFSrn5eUFE5iPiVAZrX5ouWREATUfYae/92OZXkLPd4JCyEaxSaslWCgrFawOdy/YpuAT di+WAs/Q==; Received: from dg by mx.treblig.org with local (Exim 4.94.2) (envelope-from ) id 1qDwkX-00GBMN-U9; Tue, 27 Jun 2023 00:40:05 +0000 Date: Tue, 27 Jun 2023 00:40:05 +0000 From: "Dr. David Alan Gilbert" To: Steve French Cc: Dave Kleikamp , sfrench@samba.org, linkinjeon@kernel.org, jfs-discussion@lists.sourceforge.net, linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Duplicate unicode tables in smb/cifs/jfs Message-ID: References: <25821273-d391-1502-ff8a-07ea7a59c8f3@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Chocolate: 70 percent or better cocoa solids preferably X-Operating-System: Linux/5.10.0-21-amd64 (x86_64) X-Uptime: 00:29:06 up 99 days, 11:03, 1 user, load average: 0.00, 0.00, 0.00 User-Agent: Mutt/2.0.5 (2021-01-21) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RDNS_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Steve French (smfrench@gmail.com) wrote: > probably is low risk to make the ksmbd/cifs (server and client) code common > for this I'm up for trying to do that mod; do you have a feel of the best way? I guess this is two copies to avoid symbol clashes if both the server and clients are built/loaded on the same kernel? I guess the clean way is to make this a separate .c/module that the others depend on and hten you have a nice single copy in the binary as well as the source. The shorter hack that at least avoids the source dupe would be to change the declarations in the uniupr.h files to a #define that then instantiates it with different names in the place those are #included. You'd want to move the uniupr.h up somewhere, to hmm fs/uniupr.h ? (Incidentally, I think the UNIUPR_NOLOWER is always defined so that whole chunk can go in both of them). I guess the next level would be trying to merge parts of server/client unicode.[ch] - but I was just eyeing up this particularly simple dupe in that odd uniupr.h. > (and leave the JFS code alone as Dave Kleikamp suggests) Well hmm; my reading is the tables that JFS uses are *identical* to these; so if this header was somewhere outside of fs/smb it could probably #include it and just use the same table, with a no-binary-change. Dave > On Mon, Jun 26, 2023 at 12:03 PM Dave Kleikamp > wrote: > > > On 6/25/23 9:28AM, Dr. David Alan Gilbert wrote: > > > Hi All, > > > I just tripped over three sets of duplicated unicode tables and > > > wondered if anyone had tried to rationalise them: > > > > > > The pair of: > > > ./fs/smb/server/uniupr.h > > > ./fs/smb/client/cifs_uniupr.h > > > > > > are identical except for formatting. > > > > > > ./fs/jfs/jfs_uniupr.c, > > > and I think this is the same with some change in variable name. > > > > From JFS's point of view, I wonder how relevant any of this code is. > > The Linux port of JFS originally was interested in compatibility with > > OS/2, which had case-insensitive file names. (Case-preserving, if I > > remember correctly, but names would match in a case-insensitive manner.) > > > > I would be surprised if anyone cares about this feature anymore. Without > > a JFS_OS2 flag set in the superblock, none of the case-conversion code > > comes into play. > > > > I assume SMB cares more about this and if Steve has an opinion on how to > > address this, I'd be happy to follow his lead. Probably better than > > ripping function out of JFS that could break some user that I'm not > > aware of. > > > > Shaggy > > > > > > > > (I'm guessing the same thing is implemented in a bunch of > > > other places as well in a different way) > > > > > > Would it make sense to swing fs/smb/server/uniupr.h up to > > > hmm, maybe fs/uniupr.h, remove any of the cifs_ prefixes > > > and then use the same include in all 3 places? > > > > > > Maybe then later look at using some of the nls code? > > > > > > Dave (who just tripped over this stuff) > > > > > > > > -- > Thanks, > > Steve -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/