Hi, Thor Lancelot Simon: > Indeed, I note that over in tech-kern there is a long running thread > in which a user, trying to debug a problem with NetBSD, complains that > internals of the cd9660 implementation are *not* properly hidden
Urm, i did not complain but asked about the API/ABI rank of those .h files in /usr/include. And i am not really a user but rather an upstream programmer of an ISO 9660 production program, who wants a decent mount environment for the results of that program. Results so far: 1 user aquired (actually for Xfburn). 3 own packages promoted from wip to pkgsrc. 2 kernel kernel bug fixes and 2 userland bug fixes are committed. 1 bug pending: kern/48815, 1 enhancement pending: kern/48808. 1 obtrusive change proposal to come for supporting large data files. (It is being tested meanwhile.) > He seems shocked > that we do not go (did not go) much farther to hide implementation > details Well, i was surprised to see obvious kernel entrails published. So i asked for instructions about how much care to take with changes. Meanwhile i learned that /usr/src/usr.sbin/makefs is compiling /usr/src/sys/fs/udf/udf_osta.c and /usr/src/usr.sbin/mtree/spec.c So strict encapsulation seems to have never been enforced. On the other hand, as system-neutral userland programmer, i would not dig in the <isofs/cd9660/*.h> files in order to find some kernel interface on which i could daringly rely. I rather have to take care to keep any system dependency in special adapter modules, so that my code stays portable. Still not decided is whether i shall keep <.../cd9660_node.h> API-compatible in my change to come. It will cost sizeof(void *) in each ISO 9660 vnode, but on the other hand it saves the work to find any includer or copier of the files which i propose to change. There are such "friends" of cd9660 and i can hardly propose to break them without providing fixes. But i already see problems with getting reviews for 48808 and for my change-to-come. And most of the known affected programs cannot easily be linked here because of obvious libc incompatibilities between CVS and NetBSD-6.1.3. So i could test only somewhat hacked versions. Note well: I don't complain. It's a do-ocracy. Have a nice day :) Thomas
