into oversized volume headers:
Query ARCBIOS for OSLoadFilename and OSLoadOptions first, rather than only
using the environment variables passed since we want to go through arcemu.
Add an ugly hack to arcemu that munges the nvram 'bootfile' variable. We
need this because bootfile will point to the volume header, which then
translates into a bogus root device of 'sd0i', or similar.
> - With the PCIe devices, it looks issuing a TX command while there's
> already a transmission in progress doesn't have any effect. In other
> words, if you send two packets in rapid succession, the second one may
> end up sitting in the TX DMA ring until another transmit command is
> issued later in the future. Basically, if re_txeof() sees that there
> are still descriptors outstanding, it needs to manually resume the
> TX DMA channel by issuing another TX command to make sure all
> transmissions are flushed out. (The PCI devices seem to keep the
> TX channel moving until all descriptors have been consumed. I'm not
> sure why the PCIe devices behave differently.)
stack instead of the continuation stack. This is for lib/36011, where
pthread gets confused since we aren't running on the regular stack.
I'm not really sure which direction to go to with this quite yet, so
make the hack hard to enable on purpose. The whole request dispatch
code needs cleaning anyway.
Makes ftp a bit more portable (not needing fparseln()) at the expense of not
supporting arbitrary long header lines, which I'm not concerned about
because we don't support header line continuation either...
provided buffer, with optional rate-limiting and hash-mark printing,
using one loop and handle short writes.
Refactor sendrequest() and recvrequest() to use copy_data().
Addresses PR 15943.
file system value for the size of device special files, as that
comes from specfs instead of the "host" file system. Therefore,
take care that getattr doesn't override the value of vp->v_size.
file server only if the op was still waiting for fetch (as opposed
to waiting for the response). Also, properly flag the possible
following inactive as an op for which we do not want to wait for
the response from the file server.
