Coda File System

Re: Coda-client-setup 0.5 released

From: Ivan Popov <pin_at_medic.chalmers.se>
Date: Wed, 9 Mar 2005 18:53:17 +0100
Hello Jan,

thanks for looking at the pathes!

> patch.no-daemonize
>     Should be fixed, you're not applying those anymore either.

Right. On the other side, I run venus in my startup script with ampersand
anyway, to let the system start even if venus hangs/crashes during startup.
The script waits for Coda being available for 4 minutes, then times out.

> patch.nokrb4
>     I don't know why configure picks up kerberos4. I could split the
>     with-crypto flag into separate -openssl -krb4 and -krb5 flags if you
>     want more control over which libraries get linked in.

My point of view is that we should never use kerberos 4.
The modular clog does not support that, and I doubt anyone runs Coda
with kerberos 4 authentication anyway.
Anybody here who does?

> patch.pioctl.h
>     I guess this should be an autoconf test, but since we already use
>     the platform check for DJGPP, I guess it can't hurt. Applied...
> 
>     Looking at the FreeBSD patch, I'm starting to wonder why everyone
>     seems to be needing this. Is there some other header that might
>     the necessary ioctl bits?

I'd like to get rid of ioctls as such. Then finally clog and friends
could work under Linux ABI on "foreign" platforms.

> patch.modular-clog
>     Not sure if I want to merge it just yet, although it looks like it
>     is getting some decent testing already.

I am aware of one person who did use it over a year, in several
scenarios and always with the expected results, but that's myself...
Oh well, of course my users do use it, but they do not
know any better, so they are happy :)

Seriously, I would not expect technical problems with the new clog.
(though unexpected problems always lurk in the dark... :)

> btw. the openssl dependency isn't necessary, we only link against it for
> the md5 and sha1 checksum functions. If the library isn't found we use
> a generic C implementation (I believe the original reference
> implementation). openssl could be providing some optimized assembly
> version for your platform, but I don't think we use these functions
> often enough that that will result in a measurable difference.

Then I'd rather omit openssl for clarity, though I _hope_ we _will_ need it
for cryptography!

> Jan

Regards,
--
Ivan
Received on 2005-03-09 12:55:08