ctld: replace macros with enums

[asomers]

Summary

for better type safety

[jhb]

usr.sbin/ctld/ctld.h

109

It's too bad we can't just use UNKNOWN here. If this were C++, these could be namespaced so you could avoid ambiguity that way?

[asomers]

usr.sbin/ctld/ctld.h

109

Yeah, namespaces would be great.
<offtopic>
In Rust, the enum itself is an implicit namespace. So you would have to refer to these elements like pg_filter::PORTAL . Much cleaner, IMHO.
</offtopic>

[jhb]

usr.sbin/ctld/ctld.h

109

C++ also lets you use the namespace I think, it's just not mandatory unless you use an enum class, though for this case an enum class so that UNKNOWN is never ambiguous is what we would want.

[jhb]

I'm somewhat torn on doing a big change while the nvme stuff is in flight, but I do think maybe we should just bite the bullet. git can handle renames pretty sanely for rebasing I think.

So what I think I would like to do is go ahead and convert ctld(8) to C++. The first commit would be to just rename all the .c files to .cc and change the Makefile, but make no other functional changes. We might need to a prep commit to add BEGIN_DECLS and END_DECLS to libiscsiutil.h. After that lands, you could rebase this and use C++ enum classes for these. I might also use classes instead of my protocol_ops structure in the nvme vs iscsi changes. It might be nice to use classes for several of the data structures in fact including auth_groups, portal_groups, etc. Also while updating certain things it might nice to use STL containers in place of queue macros, but that can be done incrementally.

[asomers]

In D48798#1114872, @jhb wrote:

I'm somewhat torn on doing a big change while the nvme stuff is in flight, but I do think maybe we should just bite the bullet. git can handle renames pretty sanely for rebasing I think.

So what I think I would like to do is go ahead and convert ctld(8) to C++. The first commit would be to just rename all the .c files to .cc and change the Makefile, but make no other functional changes. We might need to a prep commit to add BEGIN_DECLS and END_DECLS to libiscsiutil.h. After that lands, you could rebase this and use C++ enum classes for these. I might also use classes instead of my protocol_ops structure in the nvme vs iscsi changes. It might be nice to use classes for several of the data structures in fact including auth_groups, portal_groups, etc. Also while updating certain things it might nice to use STL containers in place of queue macros, but that can be done incrementally.

Go for it. I was also thinking about using STL containers instead of the NVLists.

[jhb]

In D48798#1114945, @asomers wrote:

In D48798#1114872, @jhb wrote:

I'm somewhat torn on doing a big change while the nvme stuff is in flight, but I do think maybe we should just bite the bullet. git can handle renames pretty sanely for rebasing I think.

So what I think I would like to do is go ahead and convert ctld(8) to C++. The first commit would be to just rename all the .c files to .cc and change the Makefile, but make no other functional changes. We might need to a prep commit to add BEGIN_DECLS and END_DECLS to libiscsiutil.h. After that lands, you could rebase this and use C++ enum classes for these. I might also use classes instead of my protocol_ops structure in the nvme vs iscsi changes. It might be nice to use classes for several of the data structures in fact including auth_groups, portal_groups, etc. Also while updating certain things it might nice to use STL containers in place of queue macros, but that can be done incrementally.

Go for it. I was also thinking about using STL containers instead of the NVLists.

Yeah, an unordered_map<> is just about as nice as the nvlist API.

[jhb]

FYI, one hiccup with this plan is that yacc only generates C code. I am working on creating a dedicated C API to sit between parse.y and ctld.c so that the rest of ctld can be C++. Blech.

[imp]

In D48798#1115132, @jhb wrote:

FYI, one hiccup with this plan is that yacc only generates C code. I am working on creating a dedicated C API to sit between parse.y and ctld.c so that the rest of ctld can be C++. Blech.

We have the same issue with devd

[asomers]

In D48798#1115132, @jhb wrote:

FYI, one hiccup with this plan is that yacc only generates C code. I am working on creating a dedicated C API to sit between parse.y and ctld.c so that the rest of ctld can be C++. Blech.

That's annoying. Should we deprecate the legacy config file format in FreeBSD 15, and remove it in 16? UCL is better.