From: Paul J. <pj...@en...> - 2002-02-14 23:00:15
|
On Wed, 13 Feb 2002, Martin J. Bligh replied to pj: > > > > In particular, responding to what it seems you're saying > > (just renumber and let the app adapt) I would think that > > the hot swap crowd would find this untenable. No app > > could sanely cope with having resources renumbered out > > from underneath it, without notice and without someway to > > lock critical sections on the use of those numbers, and > > adding the mechanisms and interfaces at the kernel-user > > boundary to support such notfication and/or critical > > sections would be a non-trivial amount of additional > > cruft. > > The justification I'd heard given in this forum before for doing > CPU renumbering went along the lines of "applications will want > to see CPU numbers starting from 0". Perhaps I've misconstrued > previous arguments. > > Hot swap seems a much more tenable argument for doing > renumbering - do you have other motiviations for it as well? Another motivation comes from process migration. Again, either we have to provide: 1) some sort of notification (heh you -- you're cpu/mem numbers just changed on you), and 2) critical section (dang it - quit moving me about while I rearrange my use of the cpus/mems available to me) or we need to provide a stable user view of the numbering of some set of cpus/mems, even as things move about and go away behind the scenes. > There seems to be a general drift towards over-complicating > things around here .... I'd rather we resist that as much as > possible ;-) Yup, though simplicity is in the eye of the beholder ... Good system calls are like good Lego(tm) bricks - classic designs of essential basic shapes that will be used in ways unimagined by the creator of the brick. Bad system calls are like the special Lego bricks scene in just one set -- overly elaborate specialized pieces that tend to break more easily, and seldom show up in other Lego models. Or, for a more bizarre analogy, the kernel is like (1) the small intestine, the libraries like (2) the liver, and the apps like (3) various other body parts. The first breaks down what's available (hardware capability or food), providing the basic nutrients (or system calls) to the second (libraries or liver) to be constructed into the various specialized capabilities (or complex organic compounds) required by the third (apps or arms). One doesn't need to eat eyeballs to see. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj...@sg...> 1.650.933.1373 |