linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* QNX EFS Driver
@ 2012-03-22 18:24 Kai Bankett
  2012-03-23 13:28 ` Matthew Wilcox
  0 siblings, 1 reply; 2+ messages in thread
From: Kai Bankett @ 2012-03-22 18:24 UTC (permalink / raw)
  To: linux-fsdevel

Hi together,

I did not lazily put my legs up ... (in case someone got that impression)
Had to reverse engineer another QNX filesystem first. (for what I want 
to achieve with all that QNX stuff)
However, at that stage I greatly could need some inspiration by you on 
how to improve driver quality. (not the nicest peace of code I ever 
wrote ...)

The QNX EFS Filesystem is used in flash devices and created during the 
build process. The EFS file is the flashed onto the flash chips in 
embedded designs.

Due to the fact that the QNX EFS Filesystem is not using any fixed 
blocks and just some fixed structures, I started fighting against the 
buffer head blocksize.
I think I could pretty up the code a lot if there's any way to read N 
Bytes from a device at position X.
Already started to look around, but could not really find something 
giving me direct position access to a device.

Well, maybe there's a even better way to solve things? (so feedback 
very, very welcome)

But first here's the patch (as it currently is):
http://a6.ontika.net/patches/efs-patch-v3.gz

At least I would be extremly thankful if someone could point me some 
direction on how to better solve the chunkreading in qnxefs_file_read().
It's currently buffer_head based with a blocksize of 512kb. The QNX EFS 
- at least the files I got hold of - uses 16384 byte Blocks in 262144 
byte logical units.
So a file is split into chunks of up to 0x4000 size, but that chunks can 
vary in size. (in case of the end of a logical unit, file end etc.)

Hope I am not boring you too much with all my QNX stuff ;)

Thanks,

Kai

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: QNX EFS Driver
  2012-03-22 18:24 QNX EFS Driver Kai Bankett
@ 2012-03-23 13:28 ` Matthew Wilcox
  0 siblings, 0 replies; 2+ messages in thread
From: Matthew Wilcox @ 2012-03-23 13:28 UTC (permalink / raw)
  To: Kai Bankett; +Cc: linux-fsdevel

On Thu, Mar 22, 2012 at 07:24:35PM +0100, Kai Bankett wrote:
> Due to the fact that the QNX EFS Filesystem is not using any fixed  
> blocks and just some fixed structures, I started fighting against the  
> buffer head blocksize.
> I think I could pretty up the code a lot if there's any way to read N  
> Bytes from a device at position X.
> Already started to look around, but could not really find something  
> giving me direct position access to a device.

Sure; there's no need to use buffer_heads at all.  You can call
submit_bio() to do reads and writes.  You do have to be 512-byte aligned,
but that doesn't seem to be an issue for you.  btrfs, ext4, gfs2, hfsplus,
jfs, logfs, nfs, nilfs2, ocfs2 and xfs all use the submit_bio interface
in case you need to see some examples.

> At least I would be extremly thankful if someone could point me some  
> direction on how to better solve the chunkreading in qnxefs_file_read().
> It's currently buffer_head based with a blocksize of 512kb. The QNX EFS  
> - at least the files I got hold of - uses 16384 byte Blocks in 262144  
> byte logical units.
> So a file is split into chunks of up to 0x4000 size, but that chunks can  
> vary in size. (in case of the end of a logical unit, file end etc.)

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-03-23 13:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-22 18:24 QNX EFS Driver Kai Bankett
2012-03-23 13:28 ` Matthew Wilcox

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).