David Brownell wrote:
+static ssize_t at24_iface_read(struct at24_iface *iface, char *buf, + off_t offset, size_t count)
I think it would have been better to pass 'void *' to these methods, which they could cast to 'struct at24_data *', than to waste memory on storing 'struct at24_iface' within 'struct at24_data' just to make use of container_of() here...
Again, why "better"?
To avoid the useless inclusion of the instance of 'struct at24_iface' into 'struct at24_data' -- that instance, if you insist on using it, should be a 'static const' variable.
You're going in circles here. You don't like it, so it's bad
We both do.
because it's not the solution you would like. This doesn't
You like your solution and dislike mine, so you choose to either ignore my arguments or make fun of them.
answer my question, unless "better because you don't like it" could be considered a technical response.
Which question I didn't answer? I thought I have argumented my dislike.
... wanting to pass void* as an instance ID
Passing "void *" is generally considered worse
That didn't stop you from using 'void *context' as an argument. ;-)
The void* that's "worse" is one that must only point to a specific type of object. When the type has that kind of restriction, using void* is nothing but bug-bait.
It's OK when the point is explicitly to pass around a handle of arbitrary type, for interpretation by whatever provided it in the first place -- the role of caller "context" in this and many other interfaces.
You have yourself said that you'd like to use this approach uniformly in several drivers -- which would naturally have different device instance objects hiding behind 'void *'.
than passing values with types that the compiler can verify.
Oh yeah, let's pass values that don't make sense just to make compilers happy. Despite one can always cheat compiler by using a type cast on a pointer argument or just passing NULL.
I don't _usually_ find myself craving quotes from Star Trek's Mr. Spock about "illogic" ...
The code you're objecting to has a type which *does* make sense.
No, it doesn't in the context of the driver's methods that get it passed. The interface structure itself if of no use to anyone but the client, and passing it as argument to the driver's methods listed in it serves no purpse other than to abuse it with container_of().
Sigh.
Ugh. Don't frighten me with a picture of this container_of() trick repated in 8 more drivers. :-]
You really need to look at more kernel code. It's not a "trick",
I really don't need advices like that -- I've seen anough of that code.
it's an *EXTREMELY COMMON* idiom that's very widely used when
It's a very tricky idiom. There's no guarantee that the object passed is really a member of the structure that the code using container_of() supposes it is. If it's not, this will "fail rudely". Also, I'm not objecting to this idiom in general, I mainly object to you wasting memory on the stucture that has no other use to the driver itself than to serve as a "token" to be passed by a client.
interfacing ... it gives information hiding with negligible cost. (A constant addition or subtraction, often merged with other address calculations for a net cost of zero.)
Heh, 'void *' would even give it at no cost... WBR, Sergei _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
