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