netsmb: absorb libmchain module

[mhorne]

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.

[glebius]

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.

[mhorne]

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.

[glebius]

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.

[emaste]

Note that netsmb in its current state is nonviable, but Illumos and Apple added smbv2/smbv3 support and that may be an update path for us.

[mhorne]

Closing some old reviews. I won't be pursuing this.