On Sat, 6 May 2000, Alan Cox wrote:
>
> So the callback knows what is going on. Like umm Duh ???
Yes. However, that doesn't change the fact that if only the low-level FS
knows what is going on, then those damn cookies shouldn't be in the VFS
layer AT ALL. It's a design mistake to have anonymous pointers.
Proper data structures and type checking are important. Cookies defeat
_both_ of those things. They make the code unreadable, and mean that the
interfaces that the VFS layer defines become "soft". Suddenly, any changes
in the VFS interfaces become damn hard to do, because the VFS layer is no
longer aware of what isreally happening. Things turn blurry.
The current VFS interfaces tend to be quite crisp. And I very much like it
that way.
Using a "void *" as a way of saying "this is an opaque pointer, don't
care, we'll cast it to what we think is the right type later" is an
absolutely _evil_ and disgusting construct.
If you'd bother to take a look, you'd notice that I've pretty much never
allowed void pointers in the core kernel code. As far as I'm concerned, it
is a sign of bad design and horrible maintenance.
"void *" is acceptable for two things:
- memory allocators return "void *". It truly is a generic pointer, and
the allocator had better cast it immediately (and that should be an
implicit cast due to a pointer assignment). The memory free routine
obviously also takes a void * argument.
- functions that truly don't care (and never will, ie it never gets
casted to anything else downstream) get a "void *". This is stuff like
memcpy(), memset() etc.
Using them this way as cookies is just ugly, and admitting that the VFS
layer no longer knows what is going on. You just lost all control and
sanity checking.
(Yes, the VFS layer does have the "readdir()" thing. I don't much like it,
and I did it that way because it had to be done that way lest it explode
in our face. But at least there you clearly pass in both the data and the
"action pointer", so you clearly keep them together and it's more of a
data packet than anything else. And "readdir()" is a rather specific
interface with not a lot of room for confusion about what it should do).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:20 EST