Re: [PATCH 1/1] Bluetooth: Split bt_iso_qos into dedicated structures

[Iulia Tanasescu <iulia.tanasescu@nxp.com>]

Hi Luiz,

I have investigated some possible ways to update my patch using your
suggestions.

I think the most convenient method would be to implement the structure
as an union of dedicated parameters and to add an additional parameter
that would indicate the type of QoS the structure is holding.

It would be something like this:

struct bt_iso_bcast_qos {
    union {
        struct bt_iso_bcast_src_qos bsrc;
        struct bt_iso_bcast_snk_qos bsnk;
    };
};

enum {
    BT_ISO_UCAST_QOS,
    BT_ISO_BCAST_SRC_QOS,
    BT_ISO_BCAST_SNK_QOS,
};

struct bt_iso_qos {
    int qos_type;
    union {
        struct bt_iso_ucast_qos ucast;
        struct bt_iso_bcast_qos bcast;
    };
};

The flow would be something like this:

At socket creation, some default unicast QoS parameters are loaded
in the qos field of the socket structure.

When the "setsockopt" function is called on an ISO socket from user
space, the user will provide a bt_iso_qos structure as defined above,
containing the type of QoS to set and the desired parameters.
The kernel will validate the parameters depending on their type, and
it will overwrite the unicast defaults if the check is succesful.

When the user calls other ISO socket APIs, like connect or listen,
and the procedures to execute are broadcast related, the kernel will
either use the QoS options that had been previously set by the user,
or, if the user did not set any options, the unicast defaults will
be replaced with broadcast defaults, and the procedures will start
this way.

Do you think this is a good design? Please let me know if I should
proceed with this implementation.

Regards,
Iulia