Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen@asianux.com>
To: Scott Lovenberg <scott.lovenberg@gmail.com>
Cc: "sfrench@samba.org" <sfrench@samba.org>,
	linux-cifs <linux-cifs@vger.kernel.org>,
	samba-technical@lists.samba.org, Jeff Layton <jlayton@redhat.com>
Subject: Re: [PATCH 2/2] cifs: Correct comment about domainname length
Date: Tue, 30 Jul 2013 08:31:09 +0800	[thread overview]
Message-ID: <51F7094D.607@asianux.com> (raw)
In-Reply-To: <51F70456.3050901@asianux.com>

On 07/30/2013 08:09 AM, Chen Gang wrote:
> On 07/30/2013 05:10 AM, Scott Lovenberg wrote:
>> On Mon, Jul 29, 2013 at 4:17 PM, Jeff Layton <jlayton@redhat.com> wrote:
>>>>>> Still, how can we have a FQDN that's 256 characters long when the host
>>>>>> name length can be 1024 characters long?
>>>>>>
>>>>>
>>>>> Excuse me, I am not quite familiar about cifs, so can not provide
>>>>> additional more information (I found it only by reading code).
>>>>>
>>>>> But I feel, it really need additional discussion and check by the
>>>>> related experts (related members who are familiar with cifs).
>>>>>
>>>>> Welcome any members' suggestions and completions.
>>>>>
>>>>> Thanks.
>>>>
>>>> Come on guys, enough already. As per here:
>>>> https://en.wikipedia.org/wiki/Domain_Name_System
>>>>
>>>> and a comment above the max len of the fully qualified domain name (FQDN) is
>>>> 63 octets per label and 255 bytes per FQDN. This maximum includes 254
>>>> bytes for the FQDN and one byte for the ending dot.
>>>>
>>>
>>> Ok, I think I knew that at one point and paged it out. It does make one
>>> wonder why NI_MAXHOST is so big though -- is that for some
>>> internationalization scheme?
>>>
>>> --
>>> Jeff Layton <jlayton@redhat.com>
>>
>> I guess it works if you're storing as UTF-32 or wchar_t at 4 bytes per
>> character. 256 characters * 4 bytes/char + 1 byte for NULL.  Microsoft
>> seems to use the same value for NI_MAXHOST ref:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms738532(v=vs.85).aspx
>> .
>>
> 
> As far as I know, the kernel implementation wants to use 255 + 1 as
> character count, not bytes count for FQDN (256 bytes for 8-bit, 512
> bytes for 16-bit, ...), it can be translated into uni-code or other
> format within 255 + 1 character count.
> 
> May it be useful for our discussion ?
> 
> (BTW: if kernel really wants to do, I also suggest to check the kernel
> implementation for it whether correct or not).
> 
> 
> Thanks.
> 

OH, sorry, what I said above is incorrect. The kernel implementation use
255 + 1 as bytes, it can be translated into uni-code within 255 + 1
character count.

For NI_MAXHOST, I think we do not mind it: WIKI is more common than
Microsoft. and Microsoft also says: "To simplify determining buffer
requirements ..." (I guess, the "simplify determining" is
"sizeof(UTF-32) * 256 + '\0'").


:-)

Thanks.
-- 
Chen Gang

  reply	other threads:[~2013-07-30  0:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 18:34 [PATCH 1/2] cifs: Move and expand MAX_SERVER_SIZE scott.lovenberg
     [not found] ` <1374777285-25639-1-git-send-email-scott.lovenberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-25 18:34   ` [PATCH 2/2] cifs: Correct comment about domainname length scott.lovenberg-Re5JQEeQqe8AvxtiuMwx3w
     [not found]     ` <1374777285-25639-2-git-send-email-scott.lovenberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-26  0:40       ` Chen Gang
     [not found]         ` <51F1C564.5070006-bOixZGp5f+dBDgjK7y7TUQ@public.gmane.org>
2013-07-26 18:12           ` Scott Lovenberg
     [not found]             ` <CAFB9KM2zF9m4Y4vcDRkZpMfvWP8NQWYKQTeJTiwgVVVu=4M6Cw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-29  0:27               ` Chen Gang
2013-07-29  0:36                 ` Richard Sharpe
     [not found]                   ` <CACyXjPxffbb8VQ55mCWTCP-GDivijXVkHNwtkVTwgAmi1XMyQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-29 18:05                     ` Scott Lovenberg
2013-07-29 20:17                     ` Jeff Layton
     [not found]                       ` <20130729161709.19c52e0f-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2013-07-29 21:10                         ` Scott Lovenberg
     [not found]                           ` <CAFB9KM3CxJcHdFPrGTW595hjNzvYnLgVA6F8J3EMdddz3n0ivw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-07-30  0:09                             ` Chen Gang
2013-07-30  0:31                               ` Chen Gang [this message]
2013-07-25 18:55   ` [PATCH 1/2] cifs: Move and expand MAX_SERVER_SIZE Jeff Layton

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=51F7094D.607@asianux.com \
    --to=gang.chen@asianux.com \
    --cc=jlayton@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=scott.lovenberg@gmail.com \
    --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