Re: [PATCH]QNX6 filesystem (RO) driver

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


On 02/12/2012 11:43 PM, Al Viro wrote:
On Sun, Feb 12, 2012 at 11:14:38PM +0100, Kai Bankett wrote:

re junk removal from qnx4 - sure, just make is a separate patch.

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().
At least so far I could not find any additional extras.
I followed your advise and used init_special_inode() to get rid of
that printk+stuff.
Umm...  How does qnx encode device numbers for block/character devices?
Actually I have to check again. My statement was not meant to say "there are none", but so far I have not seen any. I did my reverse engineering on test qnx6 filesystems created with QNX. So far I have not analyzed these special cases. I will have to try to generate some. Will come back on that one after some analysis.
Maybe I will have time tomorrow to dig a bit deeper into that ...
Anyways, the init_special_inode() at the final end seems to be right there, so at least one point less on the list.
A few more things:
	* duplicating di_block_ptr[] array seems to be pointless
Again, well spotted. Just removed the "raw" thing.
To me just taking the required stuff into qnx6_inode_info gives better control and more speed.
	* qnx6_get_inode_loc(), qnx6_dir_lfile_block() and qnx6_block_map()
seem to have a lot of duplicated code, at the very least.  Looks like
a missing helper function...
Yep. With the write code it will become even more.
Solution found. Just block_map() survived.
Incidentally, I'd switched qnx6_get_devblock()
and qnx6_check_blockptr() to __fs32 argument, along with making QNX6_PTR_UNSET
(~(__fs32)0)
That was my exactly first approach.
However, I finally decided to move away from that.
My thinking was that maybe qnx6_get_devblock() in the future may be called from with a non-__fs32 value holding function. Also, If I see it right, it won't save any cpu cycles + getting to a "uniformed" endianess directly at the fs address pointer reading functions makes the endianess border very clear when reading the source. Feedback very welcome. Easy to change, if you think __fs32 arguments make more sense.
	* what is actually stored in ->de_size for long entries in case
of big-endian fs?  4 bytes of de_inode - fine, as as for short ones, but
then what?  If it's really 32bit big-endian 0xff, it will have the first byte
equal to 0, which would confuse the living hell out of your code.  Or is
it actually __u8 + 3 bytes of padding?  Then it would be compatible with
short dir entries, but conversions would be the wrong thing to do there...
Checked against a hexdump. The de_size for long filename direntries is just a single byte.
Corrected - thanks.
	* I seriously suspect that you want to cook yourself a couple of
unhashed in-core struct inode for Longfile and Inode ones; then get_inode_loc(),
dir_lfile_block() and block_map() would become identical *and* you just might
be able to use page cache instead of all that messing with buffer_heads in
readdir et.al.  Just do new_inode() and fill di_block_ptr/levels/i_mode/i_size
and ->a_ops.  iput() both in ->put_super() and that's it...  For directories
in pagecache see how e.g. ext2 is doing it - or minixfs, for that matter.
I had a look at that point.
After successfully switching find_enty() to pagemap I spend quite some time on switching long_match() to pagemap cache.
At the end I gave up. Things just became too complicated.
Far more complicated than bh stuff.
At least if I get no further clue on how to manage the different pagesizes efficient - compared to the very efficient bh code - I cannot see light at the end of the tunnel. For long Filenames, the Filename always is stored in a seperate block. Whatever I tried, I did not get the pagemap code as efficient, as it abstracts from blocksize. (that's where it got it's stength - IHMO) Ok, I could save the block adressing steps, but I will add so many other steps on the way ... I am really unsure if that pays off at the end. At least code complexity rises extremely.
Extremley happy if you could give me some additional guidance an that point.
	* mmu_private is never used.  Just lose it...

It's history.

Updated Patch: http://a6.ontika.net/patches/patch-3.2.5-qnx6-v2.gz
Signed-off-by: Kai Bankett <chaosman@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux Ext4 Filesystem]     [Ecryptfs]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [CEPH Filesystem]


  Powered by Linux