From: Jiri Slaby <jirislaby@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Bryan Wu <cooloney@kernel.org>,
sam@ravnborg.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] Blackfin OTP Char Driver: add writing support of OTP
Date: Mon, 13 Oct 2008 12:35:27 +0200 [thread overview]
Message-ID: <48F3246F.2060104@gmail.com> (raw)
In-Reply-To: <8bd0f97a0810130307i29e76f6w62f9797b561b4c6f@mail.gmail.com>
On 10/13/2008 12:07 PM, Mike Frysinger wrote:
> the pos gets updated every time a half-page gets processed. so if you
> call write() and tell it to write 128 bytes, but you get an error half
> way through, the pos points right at the place where the error
> occurred. i dont get what you're asking.
Ah, OK, that's because I don't know exactly what should happen if a write fails.
I though userspace expects the state of the fd to not be touched.
>> But is this OK to you:
>> PROCESS 1 PROCESS 2
>> lock
>> set allow_writes
>> write
>> check allow_writes
>> be interrupted
>> whatever
>> unlock
>> unset allow_writes
>> sleep
>> mutex lock
>> the processing...
>
> i dont see a problem here. there is no loss of data, hardware
> failure, software crashes, etc... in other words, there is no
> misbehavior.
I see no purpose of allow_writes then. Why is it there? I don't need to call
memlock if anybody else did and I raced with him. Also when somebody else
unlocks after finishing of writes I can start failing in the middle of my writes
-- this doesn't have anything to do with locking, but with the design, the one
global variable.
next prev parent reply other threads:[~2008-10-13 10:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 9:13 [PATCH 1/1] Blackfin OTP Char Driver: add writing support of OTP Bryan Wu
2008-10-13 9:37 ` Jiri Slaby
2008-10-13 9:43 ` Mike Frysinger
2008-10-13 9:59 ` Jiri Slaby
2008-10-13 10:07 ` Mike Frysinger
2008-10-13 10:35 ` Jiri Slaby [this message]
2008-10-13 10:44 ` Mike Frysinger
2009-09-23 17:38 ` [PATCH v2] bfin-otp: add writing support Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48F3246F.2060104@gmail.com \
--to=jirislaby@gmail.com \
--cc=cooloney@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=vapier.adi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.