FAST - enable by default?
hartmans at MIT.EDU
Tue Apr 7 10:39:19 EDT 2009
>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:
Zhanna> Well, another approach would be dividing the code into
Zhanna> smaller files in such way that when constructing the
Zhanna> client one would pick up the object files needed to
Zhanna> fulfill the functionality requirement. Basically, build
Zhanna> the whole code, collect needed object files and then link
Zhanna> them into the library/appl. Thanks, Zhanna
If we could figure out how to make this work, I think it would be a good approach.
Basically what it would mean is that all you would need to do to trim
Kerberos for some environment is to patch function call tables. It
would mean that as someone trying to trim Kerberos, you are
responsible for making the system as a whole be consistent.
It would argue against linked function call tables. For example,
having one big accessor would not be a good idea because keeping track
of what goes in that would be difficult. But you could have an
accessor for GSS-API (possibly with a separate one for RC4) or
possibly one for GSS acceptors and one for GSS initiators.
But then the major trimming points would be tables of enctypes, the
export list from the libraries, and possibly a few others.
Even with this approach, there is a lot of work to do to design
current and future code so that you get optimal results when you trim
However it seems like it would be more maintainable than a lot of other approaches.
More information about the krbdev