From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Subject: Re: [9fans] some thoughts about auth* Message-ID: <20021108055645.A4309@unicorn.math.spbu.ru> References: <5997b562ef90863c347d5fa609d088da@hamnavoe.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <5997b562ef90863c347d5fa609d088da@hamnavoe.demon.co.uk> Date: Fri, 8 Nov 2002 05:56:45 +0300 Topicbox-Message-UUID: 1890e53e-eacb-11e9-9e20-41e7f4b1d025 On Thu, Nov 07, 2002 at 07:47:36PM +0000, Richard Miller wrote: > "Roman V. Shaposhnick" said: > While looking into this, I found another error in the 3e->4e > transition of the kfs network support. If you want 3e clients > to be able to mount a kfs exported by a 4e cpu server, the following > changes appear to be necessary: > > /sys/src/cmd/disk/kfs/9p1.c:72 d ./9p1.c:71 > < memmove(ou->chal, cp->chal, sizeof(ou->chal)); > /sys/src/cmd/disk/kfs/9p1.c:73 a ./9p1.c:73 > > memset(ou->chal, 0, sizeof(ou->chal)); > /sys/src/cmd/disk/kfs/9p1.c:76 a ./9p1.c:77 > > memmove(ou->chal, cp->chal, sizeof(ou->chal)); > > /sys/src/cmd/disk/kfs/auth.c:61 c ./auth.c:61 > < convM2T(in->ticket, &t, nvr.authkey); > --- > > convM2T(in->ticket, &t, nvr.machkey); That's exactly what I had in mind but was afraid to suggest :). Well, with these changes in mind now there is absolutely no place in Plan9 sources ( modulo stand alone fs ) where nvr.authkey can be found. Of course I understand that asking for ditching nvr.authkey from Nvrsafe is too much to ask, but it might be reasonable to mark it as deprecated in a header file. That way, people will be much less likely to be confused in the future. How about that ? Thanks, Roman. P.S. Is second declaration of the nvr in the disk/kfs/auth.c at line 35 really necessary ? Or is it just copy'n'paste artifact ?