PetervdPerk-NXP commented on PR #17847: URL: https://github.com/apache/nuttx/pull/17847#issuecomment-3743262246
> How to update the owner of iob? Since iob will be exchanged between the protocol stack and the driver, the current PR only records the "allocate" information, which is far from sufficient. These pieces of information may not reflect the actual owner information. You’re correct, the current implementation only tracks allocation, and I wasn’t aware that ownership could change. My assumption was that copyout typically results in freeing the buffer. If you’d like to improve the PR to handle ownership changes, please feel free to do so. > In the current PR, proc/iobinfo will search for each iob. There are duplicate pieces of information. Can they be printed in the form of iob chain, so that it is more intuitive to see the organization of iob? Regarding proc/iobinfo, the current approach searches for each IOB individually, which does lead to duplicate information. Printing the data as an IOB chain would indeed make the structure more intuitive, but that requires significant bookkeeping to reconstruct the chains. Additionally, the procfs printf API isn’t very convenient for this. For now, I’d prefer to keep it simple since the main goal is post-mortem analysis in cases like deadlocks, where you can manually rebuild the chains and identify owners. > We are also enhancing the debugging capabilities of iob internally to address issues such as iob memory leak, iob exhaustion, and iob trampling. Any additional tooling to improve IOB debugging would be extremely valuable. At present, IOB is quite complex and difficult to trace, which makes diagnosing issues challenging. Ideally, these problems would be addressed alongside the broader concerns in the NuttX networking stack (see #17299 and #5973). Unfortunately, I don’t have the bandwidth to work on this right now. Without significant improvements, the current state effectively renders the NuttX networking stack impractical for serious use, and it may be worth considering alternatives until these issues are resolved. It seems Li Auto faced similar challenges when using NuttX for its Li Auto Halo OS and ultimately decided not to use the NuttX networking stack, which is unfortunate. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
