similar to: com32/modules/disk patch to fix crash (syslinux 4)

Hey guys, I can't seem to figure out how to debug a COM32 app with GDB under qemu. I start "qemu -s" and then "gdb hello.elf ; target remote:1234" but can't set any breakpoints that work. I"m using syslinux4 (pathbased from the repo). Can anyone verify that they can use qemu+com32+gdb with something as simple as com32/samples/hello.c32 ? Also, is it

Hello, Pardon the newbee question but I'd like to be able to log to disk from within syslinux (extlinux actually, as it's a ext2 fs). fopen("w") does not appear to be implemented (returns EINVAL). Has anyone written the filesystem write support, and if not, any suggested routes? Should I just implement the lower level BIOS disk write support, add the FS layer, and go from

Here is the initial release: git://github.com/donhiatt/Syslinux-EXT2FS-Library-port.git I am very new to git so I hope I managed to get the repo setup properly. The repo is branched from 'disklib' as I plan to use it for all disk read/write access (I'm currently using modified gpllib/disk/* -- see README). Cheers, don ----- README for ext2fs module. * Description -----------

Hello, Would com32 modules be considered the same as an ordinary Linux executable with respect to LGPL? That is, as long as you released any changes to syslinux/com32 libs would you also have to release the source to the com32 module? Thanks for your time.

Hey guys, I've searched the archives but couldn't find any instructions on setting breakpoints in com32 apps. I'm trying to debug my app under Qemu. BTW, is there any limits on the amount of malloc space you can do? I'm trying to track down a reboot after a lot of mallocs. Thanks a lot.

Is there a known problem with fopen and/or fwrite in Syslinux? I'm trying to open a file to write data to but fopen( file_name, "w+" ) fails everytime. fopen( file_name, "r" ) works just fine.

On 8/17/20 1:46 PM, Daniel P. Berrangé wrote: > On Mon, Aug 17, 2020 at 07:36:00PM +0100, Richard W.M. Jones wrote: >> The Windows port of nbdkit >> (https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw) now works >> to some extent. However errno handling doesn't work. The way that >> Winsock handles errors is incompatible with the way we expect to work

Originally, I thought that since the plugin always emulates .zero with a fallback to .pwrite, we didn't need to expose the backend's .can_zero to plugins. But there is another consideration, as shown at least in the nbd plugin: a plugin may implement a .zero callback that depends on support from a remote endpoint. If the remote endpoint doesn't support zeroes, then the plugin HAS to

Hi all, I'm new here so bear with me. I am working on a project at work where we are replacing 1000+ Dell servers. When a new Dell server is delivered to one of our remote offices it will PXE boot off of the existing Dell server and install openSuse and then configure itself. We also PXE boot windows PCs in the remote offices so we needed a way to assign a large range of MAC addresses to a

Previously, we let a plugin set an error in either thread-local storage (nbdkit_set_error()) or errno, then connections.c would decode which error to use. But with filters in the mix, it is very difficult for a filter to know what error was set by the plugin (particularly since nbdkit_set_error() has no public counterpart for reading the thread-local storage). What's more, if a filter does

The concern is a client is blocked while processing a request. The nbdkit server design requires a thread per request being processed regardless of the number of connections or clients. We want to run 1000's of requests in parallel without needing a thread at nbdkit layer per request in flight. Our plugin layer is built around boost asio and a few threads in a worker pool running an io

It is very unlikely that the value of errno after completing the glue code in between the completion of the user's callback and the point in time where we construct the client's reply is going to be untouched, which means that we are likely to send the wrong error code across the wire. Add a new callback which determines whether we can trust errno; defaulting to true for C plugins, where

This morning I discovered this in the logwatch report for our external MX backup host. STARTTLS: write error=syscall error (-1), errno=32, get_error=error:00000000:lib(0):func(0):reason(0), retry=99, ssl_err=5: 206 Time(s) I also see many entries similar to this: 8: fl=0x802, mode=140777: SOCK inet04.mississauga.harte-lyne.ca/34091->(Transport endpoint is not connected): 1 Time(s)

The Windows port of nbdkit (https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw) now works to some extent. However errno handling doesn't work. The way that Winsock handles errors is incompatible with the way we expect to work errno in several ways. The long story is here: https://docs.microsoft.com/en-us/windows/win32/winsock/error-codes-errno-h-errno-and-wsagetlasterror-2

I ran into these while trying to prepare patches to add NBD_CMD_FLAG_FAST_ZERO, which will expose a new NBD_ENOTSUP wire value. Eric Blake (2): plugins: Don't lose original error when emulating FUA plugins: Permit ENOTSUP as synonym for EOPNOTSUPP docs/nbdkit-filter.pod | 11 ++++++----- docs/nbdkit-plugin.pod | 12 +++++++----- plugins/file/file.c | 16 +++++++++++-----

I want to make my nbd forwarding plugin fully parallel - but to do that, I first need to make nbdkit itself fully parallel ;) With this series, I was finally able to demonstrate out-of-order responses when using qemu-io (which is great at sending back-to-back requests prior to waiting for responses) coupled with the nbd file plugin (which has a great feature of rdelay and wdelay, to make it

The NBD protocol supports Forced Unit Access (FUA) as a more efficient way to wait for just one write to land in persistent storage, rather than all outstanding writes at the time of a flush; modeled after the kernel's block I/O flag of the same name. While we can emulate the proper semantics with a full-blown flush, there are some plugins that can properly pass the FUA flag on to the end

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not