From nobody Sat Jan 22 19:23:43 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5EE9019585C9 for ; Sat, 22 Jan 2022 19:23:56 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jh5lH525Vz3L15 for ; Sat, 22 Jan 2022 19:23:55 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qv1-xf2a.google.com with SMTP id k4so14952201qvt.6 for ; Sat, 22 Jan 2022 11:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1NAFH4tDEGuNdrr/sD/cnTAJvTZnQ0vJS+1tcbpX53A=; b=Ev3mzU2WdRNQqc/ZDuiLXFhjcWzfbjFysEHsKdH+Sm82rOhjFKkCeCvEMVvn3e8Vrs x8Np2Vup9bc+NbyTpDcvvJXt1Abtrqdq9gEm9GrLLYQZpU9N1Q1n9YwcpGZew86lhGGw DQ+9sxXsxGRM+OVU//y+qb8viBcIErilXRbaywvmcLoLFR9rnR40wC6f3hOd3AfiL3j1 N17B9BaLH4E1EFxmRwQb1i8w4jiFx2huNMzxHBNbbrwIqx3HcW5Ne8zcvy/sej+GcrCO yqtk3unYsGoSAq/mAz03odsOz7hEottoT5yD81fGFHsc8Gqm5O+fqG6nNLFeGs0aCCWF KCrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1NAFH4tDEGuNdrr/sD/cnTAJvTZnQ0vJS+1tcbpX53A=; b=zsRPal9QlhFD2keD6IDSFCVAC6tUF0cw/2FEY+AB8+x+RtmAaaYrXJ617q8MmoyBcN ix3wEgxS9Hdh674o67qOpplCc7VEZpMuu8vOhzZxEud0CLy6wuMhe+BTiLodWgyOTNBj eP+1KdMzAo39Uwyjp4QQqbQ4dcohMV4bvBbSESST9j87QcCZCYe1n300CMloTGKnynps Dyu6cFRPUIdnS3WEyREFsrqR/Pqkk7y1ANNsRvFZIjnbjgFq02zobkRxhJLU2DWovv+H +sBc8LozAgI3OzVgpBkwN4J+tnh/TQDB+HjXH2G2whb7hac+hYrfrIws1OHGi7XIfiTw ZXQA== X-Gm-Message-State: AOAM533H5UOKuliC6t1BKYUnFa9Fta2akCRivbNoOi8llmrMLmGnaxRy G+YZyjltkuxtL9Um2KZbiTZynDNU6yYarH/vBk6X0EK7fLE4xpAK X-Google-Smtp-Source: ABdhPJz40aCyiStb+Re3CVtGBlPCe6t6nsNLr6ZxlyWbm76z6zP73rTDjKv5wL9QhZQnGwO1yUExLJxcPcIVQ8Q32LM= X-Received: by 2002:ad4:5bc1:: with SMTP id t1mr9016837qvt.87.1642879435012; Sat, 22 Jan 2022 11:23:55 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> In-Reply-To: From: Mark Saad Date: Sat, 22 Jan 2022 14:23:43 -0500 Message-ID: Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Rick Macklem Cc: Yuri , Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-current@freebsd.org" , freebsd-stable Content-Type: multipart/alternative; boundary="000000000000220b6405d630ad13" X-Rspamd-Queue-Id: 4Jh5lH525Vz3L15 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount.org header.s=google header.b=Ev3mzU2W; dmarc=none; spf=pass (mx1.freebsd.org: domain of nonesuch@longcount.org designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-1.57 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[longcount.org:s=google]; NEURAL_HAM_MEDIUM(-0.10)[-0.099]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[longcount.org]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[longcount.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from]; MLMMJ_DEST(0.00)[freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000220b6405d630ad13 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 19, 2022 at 7:04 PM Rick Macklem wrote: > Yuri wrote: > > Rick Macklem wrote: > > > I have downloaded the final version of the opensolaris > > > smbfs and it looks much more reasonable to port to > > > FreeBSD. > > > > What do you mean by "final version of the opensolaris smbfs", the one > > from 2010? Please note that illumos (actively maintained fork of > > opensolaris) has a much more up to date one. > I'm not surprised that illumos will have updates. > I don't think it will affect the exercise at this time, since the current > work > is to figure out what pieces of the opensolaris code needs to be pulled > into the current smbfs to make the newer version work. > Solaris uses a very different VFS/VOP locking model, so a direct port > of the opensolaris code would be more work than I will be attempting. > > rick > > > I will be starting to work on this (and maybe Mark Saad will be > > able to help). > > > > I have no idea when I'll have code that can be tested by others. > > > > rick > > > > ________________________________________ > > From: Miroslav Lachman <000.fbsd@quip.cz> > > Sent: Monday, January 10, 2022 10:27 AM > > To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable > > Cc: Yuri > > Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 > > > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > IThelp@uoguelph.ca > > > > > > Hello Rick, > > thank you for the update and your time on smbfs. I hope OpenSolaris > > version will be portable. (or mayby some older version from Apple?) > > FreeBSD without possibility to mount smbfs is not an option for some > > projects. > > > > Kind regards > > Miroslav Lachman > > > > > > On 09/01/2022 15:46, Rick Macklem wrote: > >> Well, I took a look at the Apple code and I'm afraid I > >> think porting it into FreeBSD is too big a job for me. > >> > >> I was hoping the code would have a layer that could > >> be used as a "block box" for the VOP calls, but that > >> does not seem to be the case. > >> There is also a *lot* of code in it. > >> > >> I am going to look at the OpenSolaris code, to see if > >> I think it will be an easier port. > >> > >> rick > >> > >> ________________________________________ > >> From: Miroslav Lachman <000.fbsd@quip.cz> > >> Sent: Monday, November 1, 2021 5:47 PM > >> To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable > >> Cc: Yuri > >> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 > >> > >> CAUTION: This email originated from outside of the University of > Guelph. Do not click links or open attachments unless you recognize the > sender and know the content is safe. If in doubt, forward suspicious emails > to IThelp@uoguelph.ca > >> > >> > >> On 01/11/2021 16:55, Rick Macklem wrote: > >>> Miroslav Lachman wrote: > >>> [good stuff snipped] > >>>> Apple sources can be found there > >>>> https://opensource.apple.com/source/smb/ with all the history from > SMBv1 > >>>> to SMBv3. The files have original copyright header from 2001 Boris > Popov > >>>> (same as FreeBSD) but otherwise it is very different code due to > >>>> different kernel interfaces and so on. > >>>> With Apple and Illumos sources it is possible to have smbfs in FreeBSD > >>>> upgraded to v2 or v3 but very skilled programmer is needed for this > >>>> work. And for the past years there is none interested in this work. > >>> > >>> Although I agree that it would be a non-trivial exercise, a lot of the > Apple > >>> differences are in the "smoke and mirrors" category. > >>> Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor > >>> functions. For example: > >>> "struct vnode *vp" became "vnode_t vp" > >>> and "vp->v_type" became "vnode_type(vp)" > >>> > >>> Ten years ago, the actual semantics were very close to what FreeBSD > used. > >>> If you look at sys/fs/nfs/nfskpiport.h in older sources (around > FreeBSD 10), > >>> you'll see a bunch of macros I used to allow the Apple port to also > build/run > >>> on FreeBSD (a couple, such as vnode_t are still left because I've > never gotten > >>> around to doing the edit to replace them). > >> > >> If I see it right even the 10 years old Apple version of smbfs has > >> support for SMBv2 so if this old version is closer to FreeBSD kernel / > >> smbfs it can be a good starting point to merge changes to our smbfs to > >> have SMBv2 support on FreeBSD. > >> > >>> The hard part will be dealing with the actual VFS/VOP semantics > changes that > >>> have occurred in the last 10 years. > >>> > >>> Did they stick APSLs on the files? (If so, I think it could still be > ok, since the APSL > >>> is a lot like the CDDL. However, I'm not sure if the APSL has ever > been blessed > >>> by FreeBSD as of yet?) > >> > >> The old versions of smbfs has original copyright header and no other > >> license. Newer version has some added files with different header with > >> APSL license. For example > >> > https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html > >> > >> If license is a problem then I think it can live with APSL in the ports > >> tree as a loadable kernel module. Maybe this will be the easier for > >> development too? > >> > >>> Don't assume anything will happen, but I *might* take a look in the > winter, > >>> since outstanding NFS changes should be done by the end of 2021. > >> > >> I really appreciate your endless work on NFS on FreeBSD. Without your > >> work the NFS will be lacking behind industry standards similar to what > >> we see with smbfs. > >> And if you will have some spare time to take a look on smbfs and maybe > >> solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it > >> for many years and I know I am not alone who needs working SMB / CIFS on > >> FreeBSD. > >> > >>> It does sound like there is some interest in this and that fuse > doesn't solve > >>> the problem (at least for everyone). > >> > >> Yes, there is an interest. It was discussed few times in the past in the > >> mailing lists and web forums.freebsd.org but without anybody willing to > >> touch the code. > >> FUSE alternatives have so many problems with performance, stability and > >> configuration. > >> https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/ > >> > >> Kind regards > >> Miroslav Lachman > >> > > > > > So I am looking at the Apple and Solaris code, provided by rick. I am not sure if the illumos code provides SMB2 support. They based the solaris code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure predates smb2 . https://github.com/apple-oss-distributions/smb/tree/smb-217.19 If I am following this correctly we need to look at Apple's smb client from OSX 10.9 which is where I start to see bits about smb2 https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb This is also where this stuff starts to look less and less like FreeBSD . Let me ask some of the illumos people I know to see if there is anything they can point to. -- mark saad | nonesuch@longcount.org --000000000000220b6405d630ad13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 19, 2022 at 7:04 PM Rick = Macklem <rmacklem@uoguelph.ca> wrote:
Yur= i <yuri@aetern.org<= /a>> wrote:
> Rick Macklem wrote:
> > I have downloaded the final version of the opensolaris
> > smbfs and it looks much more reasonable to port to
> > FreeBSD.
>
> What do you mean by "final version of the opensolaris smbfs"= , the one
> from 2010?=C2=A0 Please note that illumos (actively maintained fork of=
> opensolaris) has a much more up to date one.
I'm not surprised that illumos will have updates.
I don't think it will affect the exercise at this time, since the curre= nt work
is to figure out what pieces of the opensolaris code needs to be pulled
into the current smbfs to make the newer version work.
Solaris uses a very different VFS/VOP locking model, so a direct port
of the opensolaris code would be more work than I will be attempting.

rick

> I will be starting to work on this (and maybe Mark Saad will be
> able to help).
>
> I have no idea when I'll have code that can be tested by others. >
> rick
>
> ________________________________________
> From: Miroslav Lachman <
000.fbsd@quip.cz>
> Sent: Monday, January 10, 2022 10:27 AM
> To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable
> Cc: Yuri
> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 >
> CAUTION: This email originated from outside of the University of Guelp= h. Do not click links or open attachments unless you recognize the sender a= nd know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<= br> >
>
> Hello Rick,
> thank you for the update and your time on smbfs. I hope OpenSolaris > version will be portable. (or mayby some older version from Apple?) > FreeBSD without possibility to mount smbfs is not an option for some > projects.
>
> Kind regards
> Miroslav Lachman
>
>
> On 09/01/2022 15:46, Rick Macklem wrote:
>> Well, I took a look at the Apple code and I'm afraid I
>> think porting it into FreeBSD is too big a job for me.
>>
>> I was hoping the code would have a layer that could
>> be used as a "block box" for the VOP calls, but that
>> does not seem to be the case.
>> There is also a *lot* of code in it.
>>
>> I am going to look at the OpenSolaris code, to see if
>> I think it will be an easier port.
>>
>> rick
>>
>> ________________________________________
>> From: Miroslav Lachman <000.fbsd@quip.cz>
>> Sent: Monday, November 1, 2021 5:47 PM
>> To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable
>> Cc: Yuri
>> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 1= 4
>>
>> CAUTION: This email originated from outside of the University of G= uelph. Do not click links or open attachments unless you recognize the send= er and know the content is safe. If in doubt, forward suspicious emails to = IThelp@uoguelph.ca<= /a>
>>
>>
>> On 01/11/2021 16:55, Rick Macklem wrote:
>>> Miroslav Lachman wrote:
>>> [good stuff snipped]
>>>> Apple sources can be found there
>>>>
https://opensource.apple.com/source/smb/<= /a> with all the history from SMBv1
>>>> to SMBv3. The files have original copyright header from 20= 01 Boris Popov
>>>> (same as FreeBSD) but otherwise it is very different code = due to
>>>> different kernel interfaces and so on.
>>>> With Apple and Illumos sources it is possible to have smbf= s in FreeBSD
>>>> upgraded to v2 or v3 but very skilled programmer is needed= for this
>>>> work. And for the past years there is none interested in t= his work.
>>>
>>> Although I agree that it would be a non-trivial exercise, a lo= t of the Apple
>>> differences are in the "smoke and mirrors" category.=
>>> Around OSX 10.4, they changed their VFS/VOP to typedefs and ac= cessor
>>> functions. For example:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "struct vnode *vp"= became "vnode_t vp"
>>> and "vp->v_type" became "vnode_type(vp)"= ;
>>>
>>> Ten years ago, the actual semantics were very close to what Fr= eeBSD used.
>>> If you look at sys/fs/nfs/nfskpiport.h in older sources (aroun= d FreeBSD 10),
>>> you'll see a bunch of macros I used to allow the Apple por= t to also build/run
>>> on FreeBSD (a couple, such as vnode_t are still left because I= 've never gotten
>>> around to doing the edit to replace them).
>>
>> If I see it right even the 10 years old Apple version of smbfs has=
>> support for SMBv2 so if this old version is closer to FreeBSD kern= el /
>> smbfs it can be a good starting point to merge changes to our smbf= s to
>> have SMBv2 support on FreeBSD.
>>
>>> The hard part will be dealing with the actual VFS/VOP semantic= s changes that
>>> have occurred in the last 10 years.
>>>
>>> Did they stick APSLs on the files? (If so, I think it could st= ill be ok, since the APSL
>>> is a lot like the CDDL. However, I'm not sure if the APSL = has ever been blessed
>>> by FreeBSD as of yet?)
>>
>> The old versions of smbfs has original copyright header and no oth= er
>> license. Newer version has some added files with different header = with
>> APSL license. For example
>>
h= ttps://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr= _2.h.auto.html
>>
>> If license is a problem then I think it can live with APSL in the = ports
>> tree as a loadable kernel module. Maybe this will be the easier fo= r
>> development too?
>>
>>> Don't assume anything will happen, but I *might* take a lo= ok in the winter,
>>> since outstanding NFS changes should be done by the end of 202= 1.
>>
>> I really appreciate your endless work on NFS on FreeBSD. Without y= our
>> work the NFS will be lacking behind industry standards similar to = what
>> we see with smbfs.
>> And if you will have some spare time to take a look on smbfs and m= aybe
>> solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting = for it
>> for many years and I know I am not alone who needs working SMB / C= IFS on
>> FreeBSD.
>>
>>> It does sound like there is some interest in this and that fus= e doesn't solve
>>> the problem (at least for everyone).
>>
>> Yes, there is an interest. It was discussed few times in the past = in the
>> mailing lists and web forums.freebsd.org but without anybody w= illing to
>> touch the code.
>> FUSE alternatives have so many problems with performance, stabilit= y and
>> configuration.
>> https://forums.freebsd.or= g/threads/getting-smbnetfs-to-work.78413/
>>
>> Kind regards
>> Miroslav Lachman
>>
>



So I am looking at the Apple and Solar= is code, provided by rick. I am not sure if the illumos code provides SMB2 = support. They based the solaris code on Apple SMB-217.x which is from OSX 1= 0.4 . Which I am sure predates smb2 .


If I am following this correctly we need to loo= k at Apple's smb client from OSX 10.9=C2=A0 which is where I start to s= ee bits about smb2


This is also where this stuff starts to = look less and less like FreeBSD .=C2=A0=C2=A0 Let me ask some of the illumo= s people I know to see if there is anything they can point to.



--
--000000000000220b6405d630ad13--