How to write to buffers after the allow_rw call?

[potto216]

I'm trying to implement libtock-c 's udp bind function in my forked libtock-rs code. However, when I try to add data to the buffer that holds the address that the UDP driver should bind to with buf_bind_cfg[0] = 2; I get an error of
error[E0503]: cannot use "buf_bind_cfg" because it was mutably borrowed

When should I write the address to buf_bind_cfg? Do I need a seperate share::scope call?

Below is a code snippet from the previously referenced file to provide context.
Thanks!

             share::scope::<
            (
                AllowRw<_, DRIVER_NUM, { allow_rw::RX_CFG }>,
                AllowRw<_, DRIVER_NUM, { allow_rw::CFG }>,
                Subscribe<_, DRIVER_NUM, { subscribe::WRITE }>,
            ),
            _,
            _,
        >(|handle| {
            let (rx_cfg_allow_rw, rx_allow_rw, subscribe) = handle.split();
            S::allow_rw::<C, DRIVER_NUM, { allow_rw::RX_CFG }>(rx_cfg_allow_rw, &mut buf_bind_cfg)?;

            buf_bind_cfg[0] = 2; // verify  we can write data to the buffer

            S::allow_rw::<C, DRIVER_NUM, { allow_rw::CFG }>(rx_allow_rw, &mut buf_tx_cfg)?;

            buf_tx_cfg[0] = 2; // verify  we can write data to the buffer

            S::subscribe::<_, _, C, DRIVER_NUM, { subscribe::WRITE }>(subscribe, &called)?;

            S::command(
                DRIVER_NUM,
                command::LIST_INTERFACES,
                total_interfaces as u32,
                0,
            )
            .to_result()
        })        
    }

[jrvanwhy]

In Tock 2.0, you're supposed to finish writing to the buffer before sharing it to the kernel via read-write allow. I'm not familiar with the UDP driver, but is that possible?

If not, the UDP driver's syscall API will need to be changed to make that possible.

[hudson-ayers]

The UDP driver only accesses the CFG allow buffer in two places -- once as part of the transmit command, and once as part of the "get interface list" command. Tock capsules (currently) do not take actions when allow calls are made. So it should be fine to just move the write to that buffer before the call to allow.

[potto216]

Thanks for the information about the rx_cfg buffer. Is the tx_cfg buffer code below which is in udp.c bind function actually needed for the bind command? When I look in driver.rs for the bind command it only looks like rx_cfg is used.

// Set up source address/port pair for sending. Store it in tx_cfg
  // Notably, the pair chosen must match the address/port to which the
  // app is bound, unless the kernel changes in the future to allow for
  // sending from a port to which the app is not bound.
  aval = allow_readwrite(UDP_DRIVER, ALLOW_CFG, (void *) BUF_TX_CFG, 2 * bytes);
  if (!aval.success) return tock_status_to_returncode(aval.status);

  memcpy(BUF_TX_CFG, &(handle->addr), bytes);

  syscall_return_t cval = command(UDP_DRIVER, COMMAND_BIND, 0, 0);

[hudson-ayers]

it has been several years since I have looked hard at the UDP code, so I am pretty much just reading it the same as you.

That said, as best as I can tell, the operation on the tx_cfg buffer is needed because calls to send() will look at the tx_cfg buffer to find both the dst_addr and the src_addr, and the src_addr will only be set correctly if it was put there by a call to bind().

It honestly doesn't feel like a good design now that I am looking at it (if the src_addr in tx_cfg has to match the bound address passed in the rx_cfg, why even store both?), but I don't recall if there was some reason for this that I have forgotten. I wish I commented all of the UDP file better when I first wrote it. It may be that this wart is a leftover from how the UDP driver was originally designed, with sending being written without reception support at first.

[potto216]

I appreciate the insight into the driver. I'll follow udp.c as a roadmap, but finish writing to the buffer before sharing it to the kernel via read-write allow.

[potto216]

I'm getting Err(BADRVAL) when calling the UDP bind command, but I thinnk I am passing in the same data that C's udp_send is. @hudson-ayers could you give a quick look at my interface code and see if I'm doing anyting obviously wrong? My next step is to add finer grained error messages to the UDP driver to find out why it is failing.

I compared the two buffers after the bind call between the C

BUF_BIND_CFG: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,67,2b,
BUF_TX_CFG: 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f,67,2b,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

and my calling code example udp_send.rs where the same buffers are being shown in decimal value.

buf_bind_cfg raw bytes are= [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 103, 43]
buf_tx_cfg raw bytes are= [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 103, 43, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

It appears they are the same as the C version.

[hudson-ayers]

BADRVAL indicates that the kernel is returning a value with a different type than libtock-rs is expecting. I think the problem is you are calling command(BIND..).to_result() in a place where libtock-rs is expecting a Result<u32, ErrorCode> when the bind command returns a Success variant (as opposed to a successU32 variant).

[potto216]

@hudson-ayers thanks for the explanation. Bind is returning a 128 success. Also I have TX working in my fork's branch udp. It returns a success32 of 129 and I see the over the air 6LoWPAN 802.15.4 packet. Once I get receive working should I open an issue to get a code review to determine what changes need to be made before a PR will be accepted?

[hudson-ayers]

Once you have send and receive working I would suggest just submitting a draft PR, and then we can iterate on any changes there