James Carlson writes: > Peter Memishian writes: > > > > > I see. While it is not too convenient, it is still doable. I mean > > > I can compile my driver in ON environment, but not necessary > > > persue integration into ON (if for some reason opensourcing > > > won't be possible) . Of course in that case I would need to > > > follow the evolution of Nemo API closely and be prepared to > > > modify my sources accordingly. Right ? > > > I can live with that. > > > > The slippery slope we start down here is that you make the resulting > > driver available for others to use, and they aren't careful about matching > > your driver with the appropriate build of OpenSolaris and end up with an > > unstable machine. > > You don't need to make the binary available for this to be toxic. The > source alone is bad enough. > > If some poor luser downloads your driver, compiles it, installs it, > and then patches the system, he's hosed. The system may crash, > corrupt data, or otherwise simply fall apart, and there's no way to > support it. > > That's why we're not shipping it.
Avoiding this scenario is trivial. Keep the mac kernel module binary and mac.h header file in sync in all patches, etc, and use a simple version number in mac_alloc() which is changed on every binary incompatible change. Or heck, even on every change at all. You already *HAVE* a version number (MAC_VERSION); can't it be used for this? This is obviously not ideal, but it is considerably better than nothing. Drew _______________________________________________ networking-discuss mailing list [email protected]
