You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Luke Kenneth Casson Leighton <lk...@samba-tng.org> on 2001/10/09 01:48:44 UTC

TNG services and FreeDCE development

development time estimates for TNG / dcerpc.net project tasks

dcethreads:

portability rewrite       50? (to use Apache Runtime Library for preference)
pthreads rewrite         200? (2nd preference: cut out dcethreads)


libapr_ntemu_util:

APR NamedPipe emulation   50?
NT Security emulation     50?


netlogond: 

idl file                  90
server                    76
client / test             76


samrd:

idl file [mostly done]    24
test server              120
client / test            120


lsarpcd:

idl file                 120
server                   120
client / test             80


ntlmssp and integration of ntlmssp into freedce ntlmsspauth:

server [mostly done]     100
client [just beginning]  100
credential cache          16
auth (server-side)        24
auth (client-side)        24


nt "named pipe" emulation layer:

tng server-side [done]   100 (it's basically done)
tng client-side [done]   100 (ditto)
freedce srv-side          80 (25% complete)
freedce client-side       80 (25% complete)
freedce auth integration  36 (related to rpc_binding_set_auth_info)


i've probably missed some things out, here.

times are in hours.

if anyone would like to assist with any of the above
development, your time and input would be greatly
appreciated: please register on dcerpc.net, place
an ssh public key in your user-profile and let me
know which of the above projects and tasks you would
like to help with.

minimum requirements are to have linux on, preferably
an x86 or other intel-byte-order machine (at the moment:
later on we will need to test against reverse-intel-byte-order);
ssh, cvs, gcc and other development tools;
experience or enthusiasm with c development;
lots of enthusiasm;
internet connection not blocking cvs port access.

thanks,

luke


Re: [xad] TNG services and FreeDCE development

Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
On Mon, Oct 08, 2001 at 06:09:32PM -0700, Howard Chu wrote:
> > -----Original Message-----
> > From: owner-xad@PADL.COM [mailto:owner-xad@PADL.COM]On Behalf Of Luke
> > Kenneth Casson Leighton
> 
> > development time estimates for TNG / dcerpc.net project tasks
> >
> > dcethreads:
> >
> > portability rewrite       50? (to use Apache Runtime Library for
> > preference)
> > pthreads rewrite         200? (2nd preference: cut out dcethreads)
> 
> Can you give me a bit more detail on this? In particular, I need to decide
> whether to try to port freedce to Solaris or get Sun's commercial DCE
> implementation
> instead, and try to make it all play together. What is the issue with the
> current dcethreads code? (I haven't looked at the freedce source tree yet.)

the current dcethreads library is an addition to the suite
of POSIX draft 4 emulation libraries, and the original focus
of dcethreads was to add to that suite w.r.t linux, which
was _not_ included, as linux wasn't _around_ when OSF started
DCE :)

so you may find that you don't need dcethreads, you may be
able to #define SOLARIS and compile from there, and not even
_use_ dcethreads.  you'll have to check the code.

dcethreads is a user-space emulation library on top of
sigsetjmp and siglongjump.  it is horrible, but it works.

personally, as i am doing this development without funding
at present, and my skills are on NT / unix interoperability,
as long as i have _a_ library, and _a_ platform on which
that library works, i am not the best person to ask w.r.t.
getting other OSes to work: i'll focus on the common bits
in my area of expertise.

i do, however, know of, and have been gently encouraging,
some other people to develop, relace or rewrite dcethreads,
plus there _is_ a possibility to do away with dcethreads
and use modern posix threads instead.

the disadvantage of that is that we lose thread cancellation,
which POSIX draft 4, and therefore dcethreads, provides.

given that most OSes don't support thread cancellation
without some sort of problems such as instability and
memory loss in the kernel (i.e. solaris), that's not such
a big deal.

luke.