Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

[David B. <da...@ja...>]

On Sat, 16 Jun 2007 14:25:08 +0200, neimad <ror...@gm...> wrote=
:

> Enum usb_tux_connection_t (USBDaemon_usb_enum.h) seems to duplicate
> most of enum tux_connection_t (USBDaemon_status_table.h):
>
>     typedef enum
>     {
>         USB_TUX_CONNECTION_DISCONNECT =3D 1,
>         USB_TUX_CONNECTION_CONNECT =3D 2,
>         USB_TUX_CONNECTION_ID_REQUEST =3D 3,
>         USB_TUX_CONNECTION_ID_LOOKUP =3D 4,
>         USB_TUX_CONNECTION_CHANGE_ID =3D 5,
>         USB_TUX_CONNECTION_WAKEUP =3D 6,
>         USB_TUX_CONNECTION_WIRELESS_CHANNEL =3D 7,
>     } usb_tux_connection_t;
>
>     typedef enum
>     {
>         TUX_CONNECTION_DISCONNECT =3D 1,
>         TUX_CONNECTION_CONNECT =3D 2,
>         TUX_CONNECTION_RANDOM =3D 3,
>         TUX_CONNECTION_ID_REQUEST =3D 4,
>         TUX_CONNECTION_ID_LOOKUP =3D 5,
>         TUX_CONNECTION_CHANGE_ID =3D 6,
>         TUX_CONNECTION_SLEEP =3D 7,
>         TUX_CONNECTION_WAKEUP =3D 8,
>         TUX_CONNECTION_WIRELESS_CHANNEL =3D 9,
>     } tux_connection_t;
>
> They seem to represent the same thing, so I think we should get rid of=

> one of them.
>
> 	Damien

Indeed for now they look rather the same but the second ones are at a  =

higher abstraction level.
usb_tux_connection_t are all commands supported by the USB dongle and th=
e  =

values for the USB frames so these defines can't be chnaged. There's a  =

dedicated command (first byte of the USB frame) group for all these  =

commands.
tux_connection are the commands made available to the end user through t=
he  =

api. Most of them are similar though it's not a simple call of the usb  =

functions. And we can offer more commands here that will never be  =

implemented in the USB dongle, like the random connection. It would also=
  =

be possible to have some USB commands not made available to the end user=
  =

but used as primitives by other user commands.

Actually we should have the same kind of similarity between all commands=
  =

sent to tux (commands.h) and all commands available through the api. Rig=
ht  =

now they're pretty much the same but I'd like to add more and more high =
 =

level functions in the daemon that will use the same basic set of tux  =

commands.

Now that I pointed out the difference, improvements on this are welcomed=
  =

of course.
If I rewsrite the usb files as a usb module, usb_tux_connection_t should=
  =

be private to the module and should be the basis for the USB interface a=
s  =

it's part of the functionalities of the USB dongle. This is hardware  =

driven so should be quite static.

On the other hand, we do whatever we want with tux_connection_t. If we  =

redesign the structures, we should also find a way to organize all  =

functions supported by the daemon, and these included.

David