All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Stuart Swales <stuart.swales.croftnuisk@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] adfs: add hexadecimal filetype suffix option
Date: Fri, 21 Jan 2011 17:47:17 +0100	[thread overview]
Message-ID: <201101211747.17544.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1101211431490.3490@dc5850.croftnuisk.local>

On Friday 21 January 2011 15:34:12 Stuart Swales wrote:
> 
> [PATCH] adfs: add hexadecimal filetype suffix option
> 
> ADFS (FileCore) storage complies with the RISC OS filetype specification
> (12 bits of file type information is stored in the file load address, rather
> than using a file extension).  The existing driver largely ignores this
> information and does not present it to the end user.
> 
> It is desirable that stored filetypes be made visible to the end user to
> facilitate a precise copy of data and metadata from a hard disc (or image
> thereof) into a RISC OS emulator (such as RPCEmu) or to a network share which
> can be accessed by real Acorn systems.
> 
> This patch implements a per-mount filetype suffix option (use -o ftsuffix=1)
> to present any filetype as a ,xyz hexadecimal suffix on each file.  This type
> suffix is compatible with that used by RISC OS systems that access network
> servers using NFS client software and by RPCemu's host filing system.
> 
> Signed-off-by: Stuart Swales <stuart.swales.croftnuisk@gmail.com>

The patch looks fine to me, but it tells me that you have some knowledge
and interest in this file system. Adfs is currently one of only a handful
of modules in the kernel that still uses the big kernel lock, because
nobody so far had enough motivation to fix this.

Would you be able to take a look at this? The straightforward approach
would be to add a mutex to adfs_sb_info and use that in place of
lock_kernel. It's mostly a matter of testing to make sure that no
deadlocks get introduced in the process.

	Arnd

  reply	other threads:[~2011-01-21 16:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4D2DEDDB.1070605@gmail.com>
2011-01-19 23:49 ` [PATCH] adfs: add hexadecimal filetype suffix option Andrew Morton
2011-01-21 14:34   ` Stuart Swales
2011-01-21 16:47     ` Arnd Bergmann [this message]
2011-01-21 17:26       ` Russell King
2011-01-21 22:02         ` Arnd Bergmann
2011-01-22  0:57           ` Stuart Swales
2011-01-21 14:43   ` Stuart Swales
2011-01-21 18:26     ` Andrew Morton
2011-03-23 20:36   ` Geert Uytterhoeven
2011-03-23 20:56     ` Al Viro
2011-03-23 20:58     ` Andrew Morton
2011-03-23 23:08       ` Stuart Swales

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=201101211747.17544.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=stuart.swales.croftnuisk@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.