Thanks Charles! This is exactly the kind of info I was looking for.
Giacomo
2016-11-30 22:53 GMT+01:00 Charles Forsyth :
>
> On 30 November 2016 at 21:51, Charles Forsyth
> wrote:
>
>> that the whole path name is re-evaluated 3 times
>
>
> That doesn't happen with the current implementation, b
On 30 November 2016 at 21:51, Charles Forsyth
wrote:
> that the whole path name is re-evaluated 3 times
That doesn't happen with the current implementation, because it walks to
the parent directory, does the create/open etc at that point with a
reference held.
On 30 November 2016 at 16:16, Giacomo Tesio wrote:
> Also I'm looking for "instances that *want* the existing effect", as
> Charles perfectly described them, something that break without it, so that
> I can dive deeper into the matter.
cat >x
x: already exists
rm x
cat >x
# different race
mk x
2016-11-30 16:40 GMT+01:00 :
> this makes no sense to me. the whole point of create with OEXCL is that
> it is atomic and it will *NOT* try to truncate-open the file when it
> already
> exist. OEXCL means just sending the Tcreate and nothing else. why is that
> not
> already what you try todo with
> Well not exactly: I will use the new create syscall (without OEXCL support)
> when I need such level of control and use ocreate with OEXCL when I do not
> care about the race and want a "create or truncate" default behaviour.
this makes no sense to me. the whole point of create with OEXCL is tha
On 30 November 2016 at 15:28, Giacomo Tesio wrote:
> I will use the new create syscall (without OEXCL support) when I need such
> level of control and use ocreate with OEXCL
Perhaps I'm confused. I thought OEXCL was just the same as the 9P create,
which is what you were trying to get.
With OEXC
2016-11-30 16:08 GMT+01:00 Charles Forsyth :
>
> On 30 November 2016 at 15:02, Giacomo Tesio wrote:
>
>>
>> But reading that thread I can't actually see why the OEXCL path has been
>> taken instead of eliminating the race mapping the syscall to the 9p message.
>> I mean except backward compatibil
On 30 November 2016 at 15:02, Giacomo Tesio wrote:
>
> But reading that thread I can't actually see why the OEXCL path has been
> taken instead of eliminating the race mapping the syscall to the 9p message.
> I mean except backward compatibility.
>
I suppose you'll find out, but I'd expect that
David it seem you walked my road already... :-)
I'm actually on a research project, so I do not care too much about the
issues on existing programs. I'm going to change/break them anyway.
Also, as far as I can foresee, it should be viable to fix such programs in
a partially automated way (eg via s
On 30 November 2016 at 13:32, wrote:
> interesting, the thread starts here:
>
> http://marc.info/?l=9fans&m=111558704718788&w=2
>
I suspect the discussion predated 9P2000 and the introduction of the OEXCL
option.
> Wow, this is a sore subject. Check the archives of this list for a
> long version of this discussion.
>
> David
interesting, the thread starts here:
http://marc.info/?l=9fans&m=111558704718788&w=2
--
cinap
Wow, this is a sore subject. Check the archives of this list for a long version
of this discussion.
David
Sent from my phone. Please excuse misspellings and terseness.
> On Nov 30, 2016, at 5:04 AM, Giacomo Tesio wrote:
>
> Hi guys, I know this is a noob question, but I'd really like to unde
it is not clear to me what your issue is. the manual clearly states
that you can pass OEXCL to create to get atomic create operation so
in what way are you trying to change the system calls?
Since create may succeed even if the file exists, a special
mechanism is necessary for
Hi guys, I know this is a noob question, but I'd really like to understand
this aspect of the kernel design.
I'm planning to experiment on the topic, modifying chan.c so that the
semantics of create(2) match those of create(5) about existing files. I
guess that the number of callers to fix is mana
14 matches
Mail list logo
