tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lockless IP input queue, the pktqueue interface
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
Home |
Main Index |
Thread Index |
Old Index