path: root/enums/msg_type.in
diff options
authorPeter Seebach <peter.seebach@windriver.com>2013-02-16 17:01:22 -0600
committerPeter Seebach <peter.seebach@windriver.com>2013-02-16 19:26:02 -0600
commit01bc8866a4aa5af17350b36e2347dc1695dbceb0 (patch)
tree590f8ed10ba2aa284e1cccbdbdefad105605a4b0 /enums/msg_type.in
parent1b774e2f832fdbcb27ddeb2cd799d156aabefb85 (diff)
If you don't want the answer, don't ask the question.
Most pseudo operations don't actually USE the server's response. So why wait for a response? This patch introduces a new message type, PSEUDO_MSG_FASTOP. It also tags pseudo operation types with whether or not they need to give a response. This requires updates to maketables to allow non-string types for additional columns, and the addition of some quotes to the SQL query enums/query_type.in table. A few routines are altered to change their behavior and whether or not they perform a stat operation. The only operations that do wait are OP_FSTAT and OP_STAT, OP_MKNOD, and OP_MAY_UNLINK. Rationale: You can't query the server for replacement information and not wait for it. Makes no sense. There's extra checking in mknod, because we really do want to fail out if we couldn't do that -- that implies that we haven't created a thing that will look like a node. The result from OP_MAY_UNLINK is checked because it's used to determine whether we need to send a DID_UNLINK or CANCEL_UNLINK. It might be cheaper to send two messages without waiting than to send one, wait, and maybe send another, but I don't want to send invalid messages. This is highly experimental.
Diffstat (limited to 'enums/msg_type.in')
1 files changed, 1 insertions, 0 deletions
diff --git a/enums/msg_type.in b/enums/msg_type.in
index 0313073..578d571 100644
--- a/enums/msg_type.in
+++ b/enums/msg_type.in
@@ -4,3 +4,4 @@ shutdown