Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: "Dr. David Alan Gilbert" <linux@treblig.org>,
	sfrench@samba.org, linkinjeon@kernel.org
Cc: jfs-discussion@lists.sourceforge.net, linux-cifs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Duplicate unicode tables in smb/cifs/jfs
Date: Mon, 26 Jun 2023 12:00:30 -0500	[thread overview]
Message-ID: <25821273-d391-1502-ff8a-07ea7a59c8f3@oracle.com> (raw)
In-Reply-To: <ZJhPIYSUzBpuqosh@gallifrey>

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)
> 

  reply	other threads:[~2023-06-26 17:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-25 14:28 Duplicate unicode tables in smb/cifs/jfs Dr. David Alan Gilbert
2023-06-26 17:00 ` Dave Kleikamp [this message]
     [not found]   ` <CAH2r5mvwZnd+S8CmZGQSdtnAWD45YjFx-1j0EaFBR3Qn-SjHEA@mail.gmail.com>
2023-06-27  0:40     ` Dr. David Alan Gilbert
     [not found]       ` <CAH2r5mvEWeSOM=NYrxSG1EZ1py-DSkOrwEyh+_L-KuFLVWktQw@mail.gmail.com>
2023-06-27 10:42         ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25821273-d391-1502-ff8a-07ea7a59c8f3@oracle.com \
    --to=dave.kleikamp@oracle.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@treblig.org \
    --cc=sfrench@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox