cvs commit: src/sys/i386/i386 trap.c src/sys/kern kern_device.c lwkt_msgport.c subr_disk.c tty_cons.c uipc_msg.c uipc_socket2.c uipc_syscalls.c src/sys/sys msgport.h msgport2.h src/sys/net netisr.c netisr.h netmsg.h src/sys/netinet ip_demux.c ip_input.c ...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

dillon      2004/04/19 18:52:28 PDT

DragonFly src repository

  Modified files:
    sys/i386/i386        trap.c 
    sys/kern             kern_device.c lwkt_msgport.c subr_disk.c 
                         tty_cons.c uipc_msg.c uipc_socket2.c 
                         uipc_syscalls.c 
    sys/sys              msgport.h msgport2.h 
    sys/net              netisr.c netisr.h netmsg.h 
    sys/netinet          ip_demux.c ip_input.c tcp_subr.c 
                         tcp_usrreq.c 
  Log:
  Revamp the initial lwkt_abortmsg() support to normalize the abstraction.  Now
  a message's primary command is always processed by the target even if an
  abort is requested before the target has retrieved the message from the
  message port.  The message will then be requeued and the abort command copied
  into lwkt_msg_t->ms_cmd.  Thus the target is always guarenteed to see the
  original message and then a second, abort message (the same message with
  ms_cmd = ms_abort) regardless of whether the abort was requested before
  or after the target retrieved the original message.
  
  ms_cmd is now an opaque union.  LWKT makes no assumptions as to its contents.
  The NET code now stores nm_handler in ms_cmd as a function vector, and
  nm_handler has been removed from all netmsg structures.
  
  The ms_cmd function vector support nominally returns an integer error code
  which is intended to support synchronous/asynchronous optimizations in the
  future (to bypass messaging queueing and dequeueing in those situations
  where they can be bypassed, without messing up the messaging abstraction).
  
  The connect() predicate for which signal/abort support was added in the last
  commit now uses the new abort mechanism.  Instead of having the handler
  function check whether a message represents an abort or not, a different
  handler vector is stored in ms_abort and run when an abort is processed
  (making for an easy separation of function).
  
  The large netmsg switch has been replaced by individual function vectors
  using the new ms_cmd function vector support.  This will soon be removed
  entirely in favor of direct assignment of LWKT-aware PRU vectors to the
  messages command vector.
  
  NOTE ADDITIONAL: eventually the SYSCALL, VFS, and DEV interfaces will use
  the new message opaque ms_cmd 'function vector' support instead of a
  command index.
  
  Work by: Matthew Dillon and Jeffrey Hsu
  
  Revision  Changes    Path
  1.50      +6 -4      src/sys/i386/i386/trap.c
  1.9       +7 -3      src/sys/kern/kern_device.c
  1.20      +97 -29    src/sys/kern/lwkt_msgport.c
  1.9       +1 -1      src/sys/kern/subr_disk.c
  1.11      +1 -1      src/sys/kern/tty_cons.c
  1.9       +242 -210  src/sys/kern/uipc_msg.c
  1.10      +4 -7      src/sys/kern/uipc_socket2.c
  1.32      +35 -6     src/sys/kern/uipc_syscalls.c
  1.17      +25 -7     src/sys/sys/msgport.h
  1.9       +47 -14    src/sys/sys/msgport2.h
  1.13      +5 -5      src/sys/net/netisr.c
  1.15      +23 -36    src/sys/net/netisr.h
  1.2       +0 -20     src/sys/net/netmsg.h
  1.19      +11 -11    src/sys/netinet/ip_demux.c
  1.19      +9 -9      src/sys/netinet/ip_input.c
  1.27      +8 -8      src/sys/netinet/tcp_subr.c
  1.16      +14 -9     src/sys/netinet/tcp_usrreq.c


http://www.dragonflybsd.org/cvsweb/src/sys/i386/i386/trap.c.diff?r1=1.49&r2=1.50&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_device.c.diff?r1=1.8&r2=1.9&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/lwkt_msgport.c.diff?r1=1.19&r2=1.20&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/subr_disk.c.diff?r1=1.8&r2=1.9&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/tty_cons.c.diff?r1=1.10&r2=1.11&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/uipc_msg.c.diff?r1=1.8&r2=1.9&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/uipc_socket2.c.diff?r1=1.9&r2=1.10&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/kern/uipc_syscalls.c.diff?r1=1.31&r2=1.32&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/sys/msgport.h.diff?r1=1.16&r2=1.17&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/sys/msgport2.h.diff?r1=1.8&r2=1.9&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/net/netisr.c.diff?r1=1.12&r2=1.13&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/net/netisr.h.diff?r1=1.14&r2=1.15&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/net/netmsg.h.diff?r1=1.1&r2=1.2&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/netinet/ip_demux.c.diff?r1=1.18&r2=1.19&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/netinet/ip_input.c.diff?r1=1.18&r2=1.19&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/netinet/tcp_subr.c.diff?r1=1.26&r2=1.27&f=h
http://www.dragonflybsd.org/cvsweb/src/sys/netinet/tcp_usrreq.c.diff?r1=1.15&r2=1.16&f=h