[1420] in Kerberos_V5_Development
On direct db access...
daemon@ATHENA.MIT.EDU (epeisach@MIT.EDU)
Tue Jul 23 09:14:54 1996
From: epeisach@MIT.EDU
Date: Tue, 23 Jul 1996 09:14:43 -0400
To: krbcore@MIT.EDU
With the new db2 code I am seeing problems on the Alpha... The problem
stems from the fact that certain assumptions are made regarding the size
of elements in the struct DBM and how they relate to the struct DB Also
at issue is the datum vs. DBT type. In the earlier berk_db version, I
modified configure to detect the difference in element sizes requiring
the the elements be copied between the structures instead of equating
the sizes. I can do this again, but personally I do not want to.
I have a number of proposals:
a) Scrap the ndbm interfaces and rewrite in db..(probably will not go
over well)
b) Make the same changes that were required for berk_db to db2...
c) Rewrite krb5_db_context to have a new type for the db_dbm_ctx (instead
of DBM * - probably void *). In the dispatch table in kdb.h, replace the
datum with another structure which will be consistant accross platforms.
I'm all for
typedef struct {
void *data; /* data */
size_t size; /* data length */
} KRB5_DBT;
this is the same size as the DBT in the db library.
Of course this means that we can not put the functions like
dbm_open.... in the dispatch table, but we need marshalling routines to
convert from our internal type (with possibly copying) to a form with
can make direct access to the libraries.
I also propose not passing structures - but instead pointers to
structures.... Reasons: Portability (I know some earlier gcc versions
had problems on HP machines) and the potential for some performance....
d) Something else....
Oh yes - while I am at it, the ODBM support in k5-int.h would be
removed.
I think you can tell what I am for.... Comments?
ezra
