linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kai Bankett <chaosman@ontika.net>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH]QNX6 filesystem (RO) driver
Date: Sun, 12 Feb 2012 04:56:29 +0000	[thread overview]
Message-ID: <20120212045629.GO23916@ZenIV.linux.org.uk> (raw)
In-Reply-To: <4F29A37F.6070909@ontika.net>

On Wed, Feb 01, 2012 at 09:41:35PM +0100, Kai Bankett wrote:

> - Endianness support
> QNX6 offers to create filesystems either little- or big endian. That's
> an advantage if the created filesystem later is used on an architecture
> that got a different endianness.
> I introduced some TO_CPUxx() macros and a superblock detection mechanism
> for detecting the FS endianness.
> Could not test it on a different architecture than x86 and therefore I'm
> unsure if it works on a different endian linux system, but from (my)
> theory it should do.
> At least on x86 it's no problem to mount a different endian QNX6 FS and
> read from it - that's what I've tested.
> If the macros are the right approach ... well, happy to receive feedback ;)

Nope, that's not the right way to do it.  Don't use __leNN for that; define
your own types.  Take a look at e.g. fs/sysv/sysv.h - __fs{16,32} in there
and functions for work with those.  And duplicate that.  What's more, you
really want the direction of conversion spelled out; sure, it's an involution
and you'll get the same code in both directions.  But it's much easier to
verify that conversions are right that way.  sparse is useful for that, BTW.
And don't use the same variable for host- and fs-endian values - it's not
worth the PITA.

Don't bother with struct qnx6_ptr - sparse _will_ complain about all places
where you do arithmetics on __bitwise types.

While we are at it, please use explicitly-sized type when you are dealing
with disk block numbers.  And pick unsigned one...

Note that unsigned long is target-dependent; on some it's 64bit, on some
32bit.  For some things that's exactly what we want, for some...

qnx6_find_bits(): what's wrong with ilog2()?  Or order_base_2(), if you
care about the case when argument itself may be not a power of 2.  Both
are in linux/log2.h...

sb_set_blocksize() may fail; check return value...

WTH are writepage and friends doing in read-only fs driver, especially
seeing that you don't seem to have anything resembling a block allocator?

qnx6_iget() - what, they really don't allow named pipes/sockets/device
nodes on the filesystem?  If not, you can just use init_special_inode()
instead of that printk+iget_failed().

_Never_ do strlen() on unsanitized on-disk data; you can't guarantee a
terminating '\0' in there.

+       /* "" means "." ---> so paths like "/usr/lib//libc.a" work */
+       if (!len && (lf->lf_fname[0] == '.') && (lf->lf_fname[1] == '\0'))
+               return TO_CPU32(dir->i_sb, de->de_inode);

Huh?  That thing is not going to get called with len == 0 and paths like
that are handled in fs/namei.c just fine without forcing every fs driver
to do that kind of contortions.  Moreover, . and .. are _also_ handled
there - ->lookup() never has to deal with those.

Incidentally, don't you have the name length right in the directory
entry?  Or is it just an upper limit?  If it's exact, it would be faster
to reject mismatches without looking at the name contents (and do memcmp()
in case of match).

  reply	other threads:[~2012-02-12  4:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01 20:41 [PATCH]QNX6 filesystem (RO) driver Kai Bankett
2012-02-12  4:56 ` Al Viro [this message]
2012-02-12 22:14   ` Kai Bankett
2012-02-12 22:43     ` Al Viro
2012-02-15  2:52       ` Kai Bankett
2012-02-15  6:10         ` Al Viro
2012-02-15  6:14           ` Al Viro
2012-02-15  6:47           ` Al Viro
2012-02-15  7:11             ` Al Viro
2012-02-15  7:57               ` Al Viro
2012-02-15 14:40                 ` Al Viro
2012-02-15 16:27                   ` Kai Bankett
2012-02-15 21:35                     ` Al Viro
2012-02-16 10:00                   ` Al Viro
2012-02-17 15:06                     ` Kai Bankett
2012-02-17 16:20                       ` Al Viro
2012-02-17 17:53                         ` Kai Bankett
2012-02-17 18:35                           ` Al Viro
2012-02-17 18:53                             ` Al Viro
2012-02-17 21:38                               ` Kai Bankett
2012-02-21 22:04                                 ` Al Viro
2012-02-21 22:09                                   ` Al Viro
2012-02-22 11:58                                     ` Kai Bankett

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=20120212045629.GO23916@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=chaosman@ontika.net \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).