6 Aug
2006
6 Aug
'06
9:59 a.m.
Ray Arachelian wrote:
Don wrote:
Yes, though you need a daemon watching for that specific purpose.
Ray Arachelian wrote:
Exactly. All the *cost*
of crossing protection domains
has the implied benefit of *enforcing* those protections.
So, maybe the "wifi server" or "ethernet server" dies and
you lose that *capability* -- but the rest of the system
keeps on ticking.
Even better, you don't lose that functionality, you restart the driver. So maybe you lose a few packets, or maybe you have to
re-establish your
WPA/WEP session to the AP, which shouldn't take all that long. So it's
the equivalent of a network burp. But likely, your applications
(perhaps even ssh sessions) will keep on working, and you don't get owned.
Depends on the service, of course. In my world, that service
may be running a motor that drives a leadscrew that positions
a cutting tool, etc. If it's not where it's supposed to be
*when* it's supposed to be there, there can be significant
consequences :-(
Hence the appeal of making sure some OTHER piece of code
doesn't misbehave and cause *this* process to hiccup.
Now, add to this the desire to let the *user*/purchaser
augment the system with their own code -- some of which
may need access to devices in a way that a traditional
approach would necessitate their inclusion in the
(monolithic) kernel and you see how quickly this can
turn into a fingerpointing contest (customer's code
doesn't work; the only way to PROVE that it is not
your liability -- legal or otherwise -- is to debug
his code and point out why it is crashing *your* code).