NetHubVirtualChannel:修订间差异

来自Bouffalo Lab Docs
跳转到导航 跳转到搜索
张良留言 | 贡献
Sync NetHub docs from local Markdown
张良留言 | 贡献
Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)
 
(未显示同一用户的3个中间版本)
第1行: 第1行:
= NetHub USER Virtual Channel =
= NetHub USER Virtual Channel =


This document describes how to use the NetHub <code>USER virtual channel</code>.
This document describes the current NetHub USER virtual channel support.
 
It focuses on USER virtual channel usage, prerequisites, APIs, and limits. For the full NetHub architecture and the broader interface support matrix, read [[NetHubArchitecture|NetHubArchitecture.md]].


== 1. Concept ==
== 1. Concept ==


<code>USER virtual channel</code> is a logical message channel carried on the current host link.
USER virtual channel is a logical message channel carried on the active host interface.


It is not a separate physical interface. It reuses the current <code>SDIO / USB / SPI</code> transport and multiplexes different payload types into separate logical channels.
It is not a separate physical interface. The public API is transport-neutral, while the current in-tree implementation is still centered on the default <code>SDIO</code> interface.


Commonly used types:
Common logical types:


* <code>USER</code>
{| class="wikitable"
** private customer or application data
|-
* <code>AT</code>
! Type !! Meaning
** host control-plane data
|-
* <code>SYSTEM</code>
| <code>USER</code> || private customer or application data
** internal system coordination messages
|-
| <code>AT</code> || control payloads
|-
| <code>SYSTEM</code> || internal coordination messages
|}


For most customer integrations, only the <code>USER</code> type matters.
== 2. Current Scope ==


== 2. Bring-Up Prerequisites ==
Current implementation summary:


Before using it, confirm:
* the public API is transport-neutral by design
* the current in-tree end-to-end USER virtual channel path follows the default <code>SDIO</code> interface
* the device-side implementation is currently in <code>backend/host/sdio/virtualchan.c</code>
* the host userspace library is currently aligned with <code>mr_sdio.ko + netlink</code>
* USB device-side ACM transport exists, but in-tree host <code>nethub_vchan</code> alignment is not finished
* SPI is not supported
 
== 3. Prerequisites ==
 
Before using the current in-tree USER virtual channel path, confirm:


* device side is built with <code>CONFIG_NETHUB=y</code>
* device side is built with <code>CONFIG_NETHUB=y</code>
* device side is built with <code>CONFIG_MR_VIRTUALCHAN=y</code>
* device side enables <code>CONFIG_MR_VIRTUALCHAN=y</code>
* host side has already loaded <code>mr_sdio.ko</code>
* the selected bring-up path uses the default <code>SDIO</code> interface
* the underlying host-device link is already working
* host side has loaded <code>mr_sdio.ko</code>
* the host-device link is already working


Additional notes:
Notes:


* The <code>USER</code> channel and the control channel are parallel channels
* USER and AT are parallel logical channels
* If the host control plane itself uses <code>vchan</code>, it uses the <code>AT</code> type
* customer private data should stay on the <code>USER</code> type
* Customer private messages should stay on the <code>USER</code> type
* documentation should not describe USB and SPI as if they already share a finished end-to-end virtual channel stack


== 3. device-side Interfaces ==
== 4. Device-Side API ==


Header:
Header:
第48行: 第64行:
</syntaxhighlight>
</syntaxhighlight>


== 4. host-side Interfaces ==
== 5. Host-Side API ==


Header:
Header:
第54行: 第70行:
* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>


=== 4.1 Initialization and Cleanup ===
Initialization and cleanup:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
第61行: 第77行:
</syntaxhighlight>
</syntaxhighlight>


=== 4.2 USER Channel ===
USER channel:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
第70行: 第86行:
</syntaxhighlight>
</syntaxhighlight>


=== 4.3 Optional State Query ===
Optional state query:
 
If you need to know whether the virtual channel is ready, you can optionally use:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
第83行: 第97行:
</syntaxhighlight>
</syntaxhighlight>


Typical checks:
Optional link event callback:
 
* <code>link_state == NETHUB_VCHAN_LINK_UP</code>
** the link is ready for TX/RX
* <code>host_state == NETHUB_VCHAN_HOST_STATE_DEVICE_RUN</code>
** the host has completed the handshake with the device
 
=== 4.4 Optional Link Event Callback ===
 
If the application wants passive notification when the link goes up or down, it can optionally register:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
第100行: 第105行:
</syntaxhighlight>
</syntaxhighlight>


== 5. Typical Usage Order ==
== 6. Typical Usage Order ==


# <code>nethub_vchan_init()</code>
# <code>nethub_vchan_init()</code>
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_send()</code>
# <code>nethub_vchan_user_send()</code>
# Call <code>nethub_vchan_deinit()</code> when finished
# <code>nethub_vchan_deinit()</code> when finished


Example:
Example:
第136行: 第141行:
</syntaxhighlight>
</syntaxhighlight>


== 6. Limits and Notes ==
== 7. Limits and Notes ==


* Maximum payload length per message is <code>1500</code> bytes
* maximum payload length per message is <code>1500</code> bytes
* The <code>USER</code> channel is packet-oriented, not a byte stream
* USER virtual channel is packet-oriented, not a byte stream
* The kernel module must be loaded before use
* the current in-tree end-to-end path is SDIO-based
* If the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the host-side <code>USER</code> channel will not work
* if the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the current in-tree USER virtual channel path will not work
* If host control-plane traffic and <code>USER</code> traffic coexist, do not reuse the <code>AT</code> type for customer private data
* if control traffic and USER traffic coexist, keep private application traffic on <code>USER</code> and do not reuse the <code>AT</code> type


== 7. Related Pages ==
== 8. Related Pages ==


* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubArchitecture|NetHubArchitecture.md]]
* [[NetHubArchitecture|NetHubArchitecture.md]]
* [[NetHub|NetHub.md]]

2026年4月24日 (五) 17:13的最新版本

NetHub USER Virtual Channel

This document describes the current NetHub USER virtual channel support.

It focuses on USER virtual channel usage, prerequisites, APIs, and limits. For the full NetHub architecture and the broader interface support matrix, read NetHubArchitecture.md.

1. Concept

USER virtual channel is a logical message channel carried on the active host interface.

It is not a separate physical interface. The public API is transport-neutral, while the current in-tree implementation is still centered on the default SDIO interface.

Common logical types:

Type Meaning
USER private customer or application data
AT control payloads
SYSTEM internal coordination messages

2. Current Scope

Current implementation summary:

  • the public API is transport-neutral by design
  • the current in-tree end-to-end USER virtual channel path follows the default SDIO interface
  • the device-side implementation is currently in backend/host/sdio/virtualchan.c
  • the host userspace library is currently aligned with mr_sdio.ko + netlink
  • USB device-side ACM transport exists, but in-tree host nethub_vchan alignment is not finished
  • SPI is not supported

3. Prerequisites

Before using the current in-tree USER virtual channel path, confirm:

  • device side is built with CONFIG_NETHUB=y
  • device side enables CONFIG_MR_VIRTUALCHAN=y
  • the selected bring-up path uses the default SDIO interface
  • host side has loaded mr_sdio.ko
  • the host-device link is already working

Notes:

  • USER and AT are parallel logical channels
  • customer private data should stay on the USER type
  • documentation should not describe USB and SPI as if they already share a finished end-to-end virtual channel stack

4. Device-Side API

Header:

  • components/net/nethub/include/nethub_vchan.h

Common APIs:

int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);

5. Host-Side API

Header:

  • bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h

Initialization and cleanup:

int nethub_vchan_init(void);
int nethub_vchan_deinit(void);

USER channel:

typedef void (*nethub_vchan_recv_callback_t)(const void *data, size_t len);

int nethub_vchan_user_send(const void *data, size_t len);
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);

Optional state query:

typedef struct {
    nethub_vchan_link_state_t link_state;
    nethub_vchan_host_state_t host_state;
} nethub_vchan_state_snapshot_t;

int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);

Optional link event callback:

int nethub_vchan_register_link_event_callback(
    nethub_vchan_link_event_callback_t callback,
    void *user_data);

6. Typical Usage Order

  1. nethub_vchan_init()
  2. nethub_vchan_user_register_callback()
  3. nethub_vchan_user_send()
  4. nethub_vchan_deinit() when finished

Example:

#include <stdio.h>
#include <string.h>

#include "nethub_vchan.h"

static void user_rx_cb(const void *data, size_t len)
{
    printf("recv USER data: %.*s\n", (int)len, (const char *)data);
}

int main(void)
{
    const char *msg = "hello from host";

    if (nethub_vchan_init() != 0) {
        return -1;
    }

    nethub_vchan_user_register_callback(user_rx_cb);
    nethub_vchan_user_send(msg, strlen(msg));

    nethub_vchan_deinit();
    return 0;
}

7. Limits and Notes

  • maximum payload length per message is 1500 bytes
  • USER virtual channel is packet-oriented, not a byte stream
  • the current in-tree end-to-end path is SDIO-based
  • if the device side does not enable CONFIG_MR_VIRTUALCHAN, the current in-tree USER virtual channel path will not work
  • if control traffic and USER traffic coexist, keep private application traffic on USER and do not reuse the AT type

8. Related Pages