Andrew Gallatin writes:
> > 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.
If you do that, then the best you get is that an upgrade breaks the
driver, and the user is still unhappy. Obviously less so than if it
trashes the system, but that's not a complete answer.
> 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.
Indeed. But even that level wasn't done here, and quite intentionally
so: it's still a private interface.
Reaching into this interface (when you're not part of the ON
consolidation) is really no different than discovering that "valuable"
data is at offset 0x120 in the middle of libc's .bss segment, and
relying on that. Or finding that you can poke location 0x122334 in
the kernel and turn on a desired feature.
It's not documented. The designer who is working on that interface
has _no idea_ that you're using it. He'll break you.
Thus I think your (non-exclusive) choices come down to:
- Tell the designer of that interface (I'm not that guy) that
you need a stable interface. Demand one.
- Use some other interface that works and is stable (such as
GLDv2 or DLPI in this case).
- Contribute to the effort by offering to work out the kinks
(changing the code if necessary) to make this a supportable
interface.
- Go ahead with hackery, and let your users sort out the
shrapnel.
I don't think this is a case that can be solved acceptably well with
bandaids. Perhaps I'm just in the minority on that.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
