[DGD] DGD and *dbm

[Shentino]

Yes, I was a bit offended, but I'm putting my attitude on hold for a
minute so I can clarify what I believe to be a misunderstanding.

btw, bart, felix's soreness is IMG (in my guess) due to a rehash of
this debate we previously had, only in private over email instead of
on the ML.

And for the record, I actually don't much mind if felix wants to be
"snobbish" about DGD.  As far as economics is concerned, he wouldn't
be doing the DGD thing at all if it weren't profitable, either
measured in money or enjoyment, it matters not to me.  That Skotos
likes it enough to willingly cough up 100K to him for the privilege of
using it speaks for itself.

<insert reference to phantasmalsite/skotos/commercial_use.html here.
I must say I don't envy his position from a business perspective.>

Given the alternatives, and especially considering how poor I am at
programming something as complex, I quite enjoy using DGD.  His
relatively courteous (compared to, say, certain companies) responses
and prompt fixes whenever I yet again manage to make DGD go boom
(i.e., segfault) only serve to his credit.

Kotaka has managed to crash DGD quite often (much to my chagrin), and
I even (until it was fixed, of course) managed to find a way to bypass
Klib security completely.  Dworkin was (and probably will be)
extremely grateful for the stream of bug reports I've been spewing in
his direction, even amid all the whining about "add this kfun" or
"implement this feature".

It's a balance.

Before I continue my ranting about wanting to save Dworkin work, I
should reveal two facts I discovered during experimentation, on a
crazy hunch.

1.  Kfuns are a scarce resource

The opcode that triggers a kfun call has only 8 bits of operand, which
means, that there can only be at most 256 kfuns in the driver.  Kfuns
are specified by 1-byte numbers, not names.

Even the +, -, <<, etc are kfuns.

Given this, I am not at all averse to being stingy with making new
kfuns.  Replace "kfun" with "oil" and place yourself in the good old
US of A, and you'll understand.

2.  Kfuns are a non-renewable resource

Once added, either through the extension mechanism or through
Dworkin's own programming, a kfun can never be removed.  The list of
kfuns is stored in the statedump, and if you try to restore a
statedump with a driver that doesn't have all the kfuns, the driver
will go "wtf is this kfun?  I don't have a friggin clue what that one
does, so I'm not going to load this alien dump".  Even recompiling
initd to remove all trace of usage of "void kfun foobar()" didn't
help.

Basically, this means that every kfun added that isn't used by a
substantial portion of the user base is a permanent and irrevocable
waste.

Already, we have 3 such kfuns.  hash_md5, hash_sha1, and hash_passwd.



These two are probably why encrypt and decrypt are two kfuns that are
in a position to handle ANY encryption algorithm for LPC.



Now, onto beefing up the extension.

My position is not to save myself work at the expense of felix's.
Rather, I see an extension interface beefup as potentially powerful
leverage, whereby some work by felix would save MANY people lots of
effort.  In fact, if the extension interface is good enough, we may
even be able to have multiple extensions SIMULTANEOUSLY.

Patching the driver to add networking or database is a pain by itself.
 Can you imagine how painful it would be to support BOTH at the same
time?

I foresee that two patches, each of which directly modify the SAME
SOURCE CODE, are going to get into a big fight if they are applied
simultaneously.

Tis true, it's asking for work from felix, however, my motives are not
entirely selfish.



The aforementioned "irreversibility" of expending 1 of a limited of
256 slots makes me hesitant to ask for a kfun however.  The LPCSSH
stuff, while overhead prone, would probably stress forward
compatibility the least.