Hacker News Reader

Given that Wifi chips already have their own ARM CPU, at this point I'd rather have that CPU which already runs its own OS to just present as a network device to do NAT. Connect it to the fixed network, use a serial link - anything will do.

At least, I'd rather have anything but the current alternative: a device on the PCI bus having DMA with a firmware I can't audit.

Same thing with WWAN device by the way.

View on HN

Not speaking specifically of the OP case, but CPU gets less and less involved in the datapath starting from a certain requirement of the max throughput. Insisting on it's going through the CPU still would raise the bar on the CPU (as a consequence, more fast RAM and increased overall power consumption, shorter battery life).

> with a firmware I can't audit.

In modern fast datapaths, there is a good deal of hardware acceleration involved, the firmware code would probably be incomprehensible without intimately knowing these.

Yes, there would be a IO load.

Tradeoffs, as always.

For some applications, I want low latency and high throughput. For others, I want security.

My understanding is that all modern OSes now use the IOMMU to protect system memory from rogue devices. Of course that protection is only as good as the PCIe implementation and the drivers doing the mapping and operating on the mapped structures.

Reply on news.ycombinator.com