netsmb: absorb libmchain module
Needs ReviewPublic
Actions

Authored by mhorne on Feb 14 2023, 2:52 PM.

Details

Reviewers

emaste
allanjude
brooks

Group Reviewers

network

Summary

This API was taken from smbfs(5) and made into a small library [1].
After two decades it has seen very few changes, and smbfs remains the
only consumer. We should keep it this way, as the smbfs module itself is
under discussion for removal. Move the logic into the netsmb module.

Bump the minor version of the netsmb module. We can add a gone_in()
warning to stable branches.

[1] d8589bd5cbad

Test Plan

make tinderbox. Load the netsmb,smbfs modules successfully.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 49779
Build 46669: arc lint + arc unit

Event Timeline

mhorne created this revision.Feb 14 2023, 2:52 PM

Herald added subscribers: glebius, melifaro, imp. · View Herald TranscriptFeb 14 2023, 2:52 PM

mhorne requested review of this revision.Feb 14 2023, 2:52 PM

Harbormaster completed remote builds in B49779: Diff 117203.Feb 14 2023, 2:52 PM

mhorne added a child revision: D38591: Remove libmchain man pages.Feb 14 2023, 2:52 PM

mhorne edited the test plan for this revision. (Show Details)Feb 14 2023, 2:54 PM

Despite the library isn't used by anything other than netsmb it seems a good one to me. I see some patterns that are implemented differently in other parts of the kernel, e.g. in socket buffers. IMHO, better keep libmchain separate from netsmb and retire them one after another. Cause netsmb has a very little chance of coming back, while the mchain library potentially can come back.

In D38590#878096, @glebius wrote:

Despite the library isn't used by anything other than netsmb it seems a good one to me. I see some patterns that are implemented differently in other parts of the kernel, e.g. in socket buffers. IMHO, better keep libmchain separate from netsmb and retire them one after another. Cause netsmb has a very little chance of coming back, while the mchain library potentially can come back.

Thanks for this input, ultimately this is exactly the kind of answer that I tagged network for. So it is useful, yet further adoption seems... unlikely? The lib has had its chance to catch on. In general we should not hesitate to eliminate stray/single-use APIs where possible (I know you are not suggesting otherwise). I am fine keeping it separate from netsmb, but I would still make the move to deprecate it now.

If it were to come back, my suggestion would be to swallow it into the regular/established mbuf API. Otherwise it will remain obscure.

In D38590#878101, @mhorne wrote:

In D38590#878096, @glebius wrote:

Despite the library isn't used by anything other than netsmb it seems a good one to me. I see some patterns that are implemented differently in other parts of the kernel, e.g. in socket buffers. IMHO, better keep libmchain separate from netsmb and retire them one after another. Cause netsmb has a very little chance of coming back, while the mchain library potentially can come back.

Thanks for this input, ultimately this is exactly the kind of answer that I tagged network for. So it is useful, yet further adoption seems... unlikely? The lib has had its chance to catch on. In general we should not hesitate to eliminate stray/single-use APIs where possible (I know you are not suggesting otherwise). I am fine keeping it separate from netsmb, but I would still make the move to deprecate it now.

If it were to come back, my suggestion would be to swallow it into the regular/established mbuf API. Otherwise it will remain obscure.

No objection on deprecating it now. Just saying that deprecating netsmb separate from libmchain would be a better process than together. It will leave a clear record that libmchain is a generic mbuf library, not a part of SMB.