11364 Want system event for datalink state changes

Review Request #2095 — Created July 8, 2019 and submitted

rm
illumos-gate
master
11364, 11365
b33b740...
general

11364 Want system event for datalink state changes
11365 Want ability to toggle etherstub link state
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>



  • 0
  • 0
  • 6
  • 1
  • 7
Description From Last Updated
tsoome
  1. 
      
  2. usr/src/uts/common/io/dls/dls_link.c (Diff revision 1)
     
     

    whitespace issue

  3. whitespace issues to line 43

  4. 
      
rm
tsoome
  1. Ship It!
  2. 
      
rm
gdamore
  1. 
      
  2. usr/src/uts/common/io/dls/dls_link.c (Diff revision 2)
     
     

    Do these really need to be SE_SLEEP? It seems to me that it won't be tragic if these events are lost due to low memory...

    1. SE_SLEEP is actually what allows us to ensure that they're not lost and for a number of cases where these things are used, a lost event can end up being pretty unfortunate. I believe that a mechanism like inotify has to basically say that events were lost and you need to rescan whatever the class of event you're looking for needs to be evolved if we want to actually have consumers that can realistically handle themselves in the face of low memory.
      
      That said, all of this is already executed from an explicit notification thread that mac creates, so I don't think the risks of having a little bit of additional blocking are going to be too bad. At least, to date, it hasn't proven to be a source of problems for us, though I can't say we've exhaustively hit all possible issues such a choice could have either way.
    2. Historically sysevent has always been best effort delivery. That was, IIRC, part of the original design that I seem to recall Cynthia created -- admittedly I'm remembering stuff from the Solaris 8 time frame (when sysevent was created, which was mostly in support of dynamic reconfiguration and in particular discovery of newly attached resources.)

      One of the concerns raised by Cynthia, again per my recollection, was that if a slow event consumer was present, it could gum up the works.

      Now, having said all that, this is happening before the event is generated, so I guess it's ok. Generally if we can't allocate memory the whole system is pretty unusable anyway... so I'll agree to let this stand as is.

  3. 
      
rm
rm
gdamore
  1. Ship It!
  2. 
      
gdamore
  1. I approved, and I'd like to see this come in soon. I've got another minor cleanup of the sysevent space (removal of stale definitions from Alternate Pathing), but I'd prefer to follow your change to minimize disrupting you.

  2. 
      
jjelinek
  1. 
      
  2. remove 2nd "that"

  3. "have a more detailed"
    "which is available"

  4. remove "detailed"

  5. This seems confusing since the list doesn't immediately follow. Maybe move this paragraph down after the following paragraph?

  6. 
      
rm
jjelinek
  1. Ship It!
  2. 
      
tsoome
  1. Ship It!
  2. 
      
rm
Review request changed

Status: Closed (submitted)

Loading...