: Why are we using libverto again
hartmans at MIT.EDU
Thu Jul 7 11:46:36 EDT 2011
>>>>> "Simo" == Simo Sorce <simo at redhat.com> writes:
Simo> On Thu, 2011-07-07 at 10:44 -0400, Sam Hartman wrote:
>> So, as far as I can tell dladdr is a glibc extension. So, we cannot
>> even guarantee it's present on Unix platforms.
>> I'm very concerned about the portability impact of this many shared
>> library tricks. Without win32 portability we can never use this in
>> libkrb5. So, it's only valuable for the KDC.
Simo> Many ?
Simo> dladdr() is the only trick I am aware of.
dlopen the application
Looking for what event libraries are already linked in.
>> Now, for the KDC today, we could just use a specific event library and
>> gain significant complexity savings.
Simo> libverto is not complex at all and saves you from forcing a specific
Simo> dependency on a system given it seem different OSs are standardizinf on
Simo> different event libraries for now.
I think it is reasonable and desirable for the KDC to pick a particular
event library when running in stand alone mode.
>> I'm quite concerned that the complexity of libverto is too great to
>> depend on just for simplifying a future libkdc.
Simo> Please take a look at the code.
I'll do that, but the bugs and type of bugs to date already exceepd my
estimate of complexity to value.
>> This is particulary true because several of the uses of libkdc such as
>> pku2u or some of the eap preauth cases would strongly benefit from
>> porting to Windows.
Simo> Windows was not stated as a necessary dependency when the project was
Simo> started. If it is now I am sure we can add it on the roadmap. The only
Simo> issue is that I know of no event libraries available in Windows at all
Simo> unless you count stuff that compiles on cygwyn/mingw which you said is
Simo> not ok.
mingw doesn't bother me so much if you can produce a dll and import
library and have no dependencies on msys.
However, libevent seems to have msvc solutions included in the source so
I suspect it does not require mingw.
>> I think we need to take a step back and carefully consider whether this
>> direction makes sense.
Simo> It definitely does, the other option is to make the KDC threaded, and it
Simo> looks like that direction is even less desirable atm.
My preferred solution is to pick a specific event library for the KDC.
The libkdc implications are not ideal, but I think this option needs to
at least be given significantly more consideration than it has been to
More information about the krbdev