On Tue, Sep 04, 2007 at 05:12:55PM -0700, Erik Nordmark wrote: > Nicolas Williams wrote: > > >IMO: a truly extensible STREAMS (or whatever) stack would have the > >ability to tag messages with typed-meta-data up (and down) the stack, > >from stream head (and application) to driver, or the reverse, visible to > >all things in between but _without_ having to make any modules aware of > >any such typed-meta-data if they don't need to consume it. > > I fail to understand what problem you are trying to solve.
Me? None. Yet. I interjected in someone else's thread :) > IMHO I see no benefits in a STREAMS beautification project, which is > what "truly extensible" reads like to me ;-) I was opining on what that an extensible STREAMS would entail, as opposed to opinining that we need one. Darren Reed's the one who seems to want it (and though he didn't call 'it' "extensible STREAMS", that was my take). > >E.g., cred_t could be seen as such meta-data if there weren't already a > >field for that in mblk. > > db_cred actual highlights the issues around the intended semantics of > any attribute - the current implementation of db_cred is underspecified > leading to potential security issues. Yup. > I don't see making it easier to define new extensions as important - > what matters is how carefully we can specify the intended semantics. The > mechanics of adding a new field to some structure is in the noise > compared to the effort to get the semantics correct. I'm not so sure. When the mechanics of ... == backwards incompatible ABI changes == update Sun, OpenSolaris and third-party source code, well, that's bad, that really puts a crimp on things. Dealing with the semantics of new extensions can be much simpler: non-critical ones should just work, and as for critical ones, criticality should be build into the system (i.e., run-time detection of whether some module understands a given critical extension). This sort of thing isn't a cake walk, but extensible protocols and extension criticality are understood well enough. But in practice the approach we've been taking of turning messaging into function calls is a very good approach for groups of adjacent protocols in the stack. We can probably make do. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
