hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fatfs locking


From: Marcus Brinkmann
Subject: Re: fatfs locking
Date: Mon, 01 Mar 2004 01:14:59 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 29 Feb 2004 15:47:32 -0800,
Thomas Bushnell, BSG wrote:
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > So, this is the main issue, and I don't feel that you have addressed
> > it at all.
> 
> Ok, thanks for your patience.  I don't mind adding an argument,
> provided the caller always knows exactly which case is being invoked,
> to tell diskfs_cached_lookup whether the lock is already held or not.
> That is, I'm comfortable provided the caller always knows whether the
> node is locked.

Yes.  The original idea was to provide the node pointer if the
directory is locked, and NULL otherwise.
 
> In other words, it should be described that the arg means "the caller
> already has the node locked", and not that the arg means "don't lock
> the node when you get it."
>
> I believe this is entirely consistent with what you have suggested;
> just please be sure to document it in such a way, so as not to imply
> that it's ever legitimate to omit the locking.

Yes, I think that is exactly what is required.  Now, hopefully you
won't fall off the chair when you see how many interfaces are affected
in the case of fatfs write support (as opposed to read support) ;)
Anyway, you are making Marco very happy.

Somebody will make a patch (Roland, do you still have your changes for
diskfs_cached_lookup?) and either check it in (in the case of Roland)
or post it (everybody else), and then there's another chance to
comment on it.

Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]