[PATCH] nvmet: parametrize maximum number of ANA groups

[Alex Talker]

 > Please no module param for this, right place is configfs subsys
 > attr.

Did you meant port attribute? Since the value mainly makes sense there.

The main obstacle for me here, since again,
i wanted to keep the change as simple as possible,
is the 'nvmet_ana_group_enabled' "array".
I have a real doubt that I do understand what it is for much
but the main issue would be if maximum number of ANA groups would 
differentiate per-port,
then how does one pre-allocates such an 'array'?
What this should be refactored to then?

 > Also, if you are doing this please make sure to write a block test
 > for these two configfs params, since it definitely adds a code that
 > user input might missuse with invalid numbers.

Could you please give me an example of such a test?

And...

 > We should keep anagrpmax a compile-time default, and have 
'nanagrpids' a per-subsystem configfs setting. That way we can limit the 
memory requirements on the connecting host (as it can/will size the ANA 
log buffer by nanagrpids), and have the value configurable per subsystem.

Would that imply that ANAGRPMAX would be set to less than the maximum 
possible value? If so, which reasonable value do you think will fit? 
2^16 or more?
Again, why 'nanagrpids' would be a subsystem attribute if validation 
comes into play(for creation of ANA group) on the port level at the moment?
And the same issue as before, what to do if the value decreases while 
groups are in use? Deny the change?

Best regards,
Alex