This allows partitions to create additional aliases of their own. The
default method implementations preserve the existing behavior.
No functional change.
cem on Thu, May 21, 3:58 AM.Authored by
Kobj dispatch is on first method argument; correct method argument order to put
Ah, your comment is that effectively "*this" has to be the first argument to kobj methods? Yes, that is true. Not sure how one would detect that at runtime in KOBJ_DISPATCH or the like though. Note that we tend to just aggregate kobj_class_t as the first member of whatever we use as the first argument, no inheritance (since it's C) so I don't think you can do much in the way of compile time checking?
Right. In retrospect, obvious, but I was perhaps being silly trying to preserve argument order so registers didn't need to shuffle and did not think about where dispatch happened.
I don't think we can generally do it at runtime. We could have some INVARIANTS-only kludge like a sentinel marker that is unlikely to match for non-KOBJs.
Well, if we didn't cast firstvar to kobj_t, the compiler would actually check the ->ops member existed. For some reason we already don't do this for STATICMETHODs, but it isn't clear to me why we do it at all.
And if KOBJOPLOOKUP() was an inline function instead of a macro (which, it can be, aside from OP##_##desc pasting), the type of the ops would be checked as well.
Correct. If you create a method that doesn't have a kobj as its first argument, you're going to have a bad time.
Though STATIC methods should be fine... but STATIC methods are a bit special in other ways :( I am surprised we don't catch it better, but looking at the casts involved and our standard practice, it looks like it would be hard to improve unless we mandated all the kobj objects have a kobj first named in a particular way, then macros could come to the rescue w/o casts... but that's its own kind of poison.
In any event, these changes look good to my eye.