search for: _implementation_

...spec ( I used http://www.pix.net/software/pxeboot/archive/pxespec.pdf ) > > sname, 64 bytes, Can be overloaded if using Opt 66 > > Hope this helps I didn't question the specification, where BOOT field sname or DHCP option 66 could be loaded with some string. I questioned if any _implementation_ (ie a PC with PXE OROM) bothers to pay attention to sname/66 before BOOTP field siaddr or if a DHCP daemon would set siaddr to 0 while setting sname/66. If the BOOTP/DHCP specifications require that siaddr be set to the first possible value of sname/66 (which I can't seem to verify with the RF...

On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Sep 12, 2015 at 10:23 AM, Geert Stappers <stappers at stappers.nl> wrote: >> Euh, could this be reviewed: >> >> diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c >> index 8d93a6a..b82e944 100644 >> --- a/core/fs/pxe/dhcp_option.c >> +++

> Perhaps, but then you need to assume that the jitterbuffer can just > throw away the data, and that limits how you can use it. In object- > oriented terms, you might want to pass objects to the JB, and then > call a destructor on them. In C terms, you may want to allocate > frames via malloc(), and then call free() on them later. You might > want to pass in

...Sounds complicated and even > technically > impossible for the general case (what if the frames *can't* be broken > down for a particular codec?). Again, I don't think the API prohibits the use that you've described. You can call jb_put() with that overlapping data. My _implementation_ may not like it, but the API can support it. > >>> Well, that API clearly has limitations that mean I can't use them >>> to do >>> what I need. Unless you're willing to change that (and even then >>> I'm not >>> sure), there's no way...