|
@@ -171,9 +171,6 @@ static int pxe_tftp_open ( uint32_t ipaddress, unsigned int port,
|
171
|
171
|
struct in_addr address;
|
172
|
172
|
int rc;
|
173
|
173
|
|
174
|
|
- /* Intel bug-for-bug hack */
|
175
|
|
- pxe_set_cached_filename ( filename );
|
176
|
|
-
|
177
|
174
|
/* Reset PXE TFTP connection structure */
|
178
|
175
|
memset ( &pxe_tftp, 0, sizeof ( pxe_tftp ) );
|
179
|
176
|
xfer_init ( &pxe_tftp.xfer, &pxe_tftp_xfer_ops, NULL );
|
|
@@ -470,17 +467,6 @@ PXENV_EXIT_t pxenv_tftp_read ( struct s_PXENV_TFTP_READ *tftp_read ) {
|
470
|
467
|
* value before calling this function in protected mode. You cannot
|
471
|
468
|
* call this function with a 32-bit stack segment. (See the relevant
|
472
|
469
|
* @ref pxe_x86_pmode16 "implementation note" for more details.)
|
473
|
|
- *
|
474
|
|
- * @note Microsoft's NTLDR assumes that the filename passed in via
|
475
|
|
- * s_PXENV_TFTP_READ_FILE::FileName will be stored in the "file" field
|
476
|
|
- * of the stored DHCPACK packet, whence it will be returned via any
|
477
|
|
- * subsequent calls to pxenv_get_cached_info(). Though this is
|
478
|
|
- * essentially a bug in the Intel PXE implementation (not, for once,
|
479
|
|
- * in the specification!), it is a bug that Microsoft relies upon, and
|
480
|
|
- * so we implement this bug-for-bug compatibility by overwriting the
|
481
|
|
- * filename stored DHCPACK packet with the filename passed in
|
482
|
|
- * s_PXENV_TFTP_READ_FILE::FileName.
|
483
|
|
- *
|
484
|
470
|
*/
|
485
|
471
|
PXENV_EXIT_t pxenv_tftp_read_file ( struct s_PXENV_TFTP_READ_FILE
|
486
|
472
|
*tftp_read_file ) {
|