Lines Matching defs:command
22 * Saved state for a command that "goes async". When a compound request
23 * contains a command that may block indefinitely, the compound reply is
24 * composed with an "interim response" for that command, and information
25 * needed to actually dispatch that command is saved on a list of "async"
33 * that there's no need to run more than one async command at a time.
40 * command in a compound. If they were to do so, the [MS-SMB2] spec.
46 * processing at the async command.
117 * Note: Cancel gets the "invalid command" handler because
179 uint16_t command;
197 command = LE_IN16((uint8_t *)sr->sr_request_buf + 12);
198 if (command == SMB2_CANCEL) {
244 * This function processes each SMB command in the current request
250 * compound we're building, and put the (now async) command on a
312 * once they're set after some command handler returns,
314 * calling the command-specific handler. The cancelled
323 sr->smb2_cmd_hdr = sr->command.chain_offset;
376 ((sr->smb2_cmd_hdr + msg_len) > sr->command.max_bytes)) {
383 msg_len = sr->command.max_bytes - sr->smb2_cmd_hdr;
387 * Setup a shadow chain for this SMB2 command, starting
388 * with the header and ending at either the next command
390 * needs the entire SMB2 command. After that's done, we
392 * the command specific handlers continue decoding.
394 (void) MBC_SHADOW_CHAIN(&sr->smb_data, &sr->command,
412 * If this command is NOT "related" to the previous,
414 * left over from the previous command.
416 * If the command IS related, any new IDs are ignored,
443 * according to the flags for the this command.
448 * This command requires a user session.
452 * Previous command should have given us a user.
481 * This command requires a tree connection.
485 * Previous command should have given us a tree.
554 * for command-specific decoding in the dispatch
564 * command are proportional to their data transfer size.
566 * Every command may request an increase or decrease of
586 * the command-specific handler returns so it won't be
629 * The real work: call the SMB2 command handler
690 (int64_t)(sr->command.chain_offset - sr->smb2_cmd_hdr));
720 * If there's a next command, figure out where it starts,
721 * and fill in the next command offset for the reply.
723 * (the offset to the next command). Similarly set
727 sr->command.chain_offset =
737 * this command (possibly part of a compound).
791 * command and reply areas as they were when the command-speicific
793 * Call the async function, which builds the command-specific part
831 (void) MBC_SHADOW_CHAIN(&sr->smb_data, &sr->command,
889 * this command (possibly part of a compound).
914 * all the state we'll need to run an async command later,
915 * and assign an "async id" for this (now async) command.
925 * willing to "go async", and only allow the last command in a
928 * simplification also means there can be at most one command
998 &sr->command, "Nwww..wwllqllq16c",
1167 * Setup sr->fid_ofile, either inherited from a related command,
1188 * handling the same command, so let's tolerate that.