Page MenuHomeFreeBSD

ctld: Add a dedicated API between parse.y and the rest of the program
Needs ReviewPublic

Authored by jhb on Tue, Feb 11, 1:20 AM.
Tags
None
Referenced Files
F110476724: D48934.diff
Tue, Feb 18, 11:55 PM
Unknown Object (File)
Tue, Feb 11, 1:52 AM
Subscribers

Details

Reviewers
asomers
Summary

The primary purpose of this is to permit the rest of ctld to use C++.
However, this also has the nice side effect of reducing code
duplication with the UCL parser.

As a general rule, setting of options including error handling for
invalid values, etc. is moved out of parse.y and into ctld.c. The
intention is that all of the functions declared in parse.h will be
extern "C" for use by parse.y.

A few other small changes are included with this refactoring:

  • Warn and fail a configuration that specifies the same LUN multiple times for a target.
  • Use T_* constants for SCSI device types instead of magic numbers.
  • Warn and fail for a few UCL properties that aren't the required type including "discovery-auth-group" in a portal group context, "auth-type" and "port" in a target context.
  • Fix a bug where chap-mutual in a target in UCL would not auto-create a new auth-group.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 62361
Build 59245: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Tue, Feb 11, 1:20 AM

FYI, I haven't uploaded it yet, but after the end of this current series I have converted ctld to compile as C++, and it was sufficient to just slap __BEGIN_DECLS and __END_DECLS around the prototypes in the new <parse.h> header (at least in terms of the interface between parse.y and the rest of ctld).

A couple of thoughts I had while mulling this further and thinking about how the nvme additions would work:

  1. Perhaps parse.h should be renamed to conf.h to allow for a future conf.cc where some of the routines might live?
  1. Perhaps portal_group_start should be setting a "hidden" global that replaces the current static globals in parse.y and uclparse.c? Similarly, there would be a global conf that means the current in-progress configuration. This would mean that the current code that assigns NULL to these globals would need to be replaced with portal_group_stop() and the like. In particular, one advantage of having this is it would hide the pointer types from this interface so that they can be come C++ classes in the future.