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.

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.