Writing a VFS driver

Writing a VFS driver

[David H. Lynch Jr.]

    I am trying to write a vfs driver for a fairly simple filesystem.

    I have been looking for a good sample to start from an most of what
I have seen is either too simple or too complex.
   
    I do not need subdirectories, hard links, symbolic links, ACL's. I
am supporting an existing ROM filesystem that
    has no superblock, Files start with a directory header that has the
filename and other attributes as text strings,
    the header is followed by the file data. The data runs contiguously
until the end of file and is then 0xff filled to the next
    2000h boundary.

    I already have a working mtd block device to access the ROM
(actually write protected flash)
   
    I am looking for something really simple to start from, but also
something that actually uses an underlying block device.
    All the "tutorial" examples I have tripped over (rkfs, ols2006
samplefs) seem to impliment in memory filesystems - unless I
    am mis-understanding how VFS to block device mapping works.

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Writing a VFS driver

[Avishay Traeger]

On Sun, 2007-01-07 at 17:36 -0500, David H. Lynch Jr. wrote:
>     I am trying to write a vfs driver for a fairly simple filesystem.
> 
>     I have been looking for a good sample to start from an most of what
> I have seen is either too simple or too complex.
>    
>     I do not need subdirectories, hard links, symbolic links, ACL's. I
> am supporting an existing ROM filesystem that
>     has no superblock, Files start with a directory header that has the
> filename and other attributes as text strings,
>     the header is followed by the file data. The data runs contiguously
> until the end of file and is then 0xff filled to the next
>     2000h boundary.
> 
>     I already have a working mtd block device to access the ROM
> (actually write protected flash)
>    
>     I am looking for something really simple to start from, but also
> something that actually uses an underlying block device.
>     All the "tutorial" examples I have tripped over (rkfs, ols2006
> samplefs) seem to impliment in memory filesystems - unless I
>     am mis-understanding how VFS to block device mapping works.

You may want to look at cramfs (fs/cramfs), which is a read-only file
system that doesn't have much code to it.

Avishay

Re: Writing a VFS driver

[Phillip Lougher]

On 7 Jan 2007, at 23:28, Avishay Traeger wrote:

> On Sun, 2007-01-07 at 17:36 -0500, David H. Lynch Jr. wrote:
>>
>>     I am looking for something really simple to start from, but also
>> something that actually uses an underlying block device.
>>     All the "tutorial" examples I have tripped over (rkfs, ols2006
>> samplefs) seem to impliment in memory filesystems - unless I
>>     am mis-understanding how VFS to block device mapping works.
>
> You may want to look at cramfs (fs/cramfs), which is a read-only file
> system that doesn't have much code to it.
>

I personally wouldn't look at Cramfs, althought it is a simple block  
device based filesystem, it has some elements such as compression,  
and non unique inode numbers that make it unnecessarily complicated  
for your needs.

I would personally use Romfs as a guide.  This, although an old  
ilesystem, has all the elements you need.   You don't mention whether  
your filesystem has unique inode numbers, but you can use the disk  
location of the inode to generate the inode number.  Doing this  
ensures your inode numbers are unique, and you can use the standard  
VFS iget routine, which can use this inode number to go straight to  
the information on disk.  You mention your filesystem aligns each  
inode on a 8 Kbyte boundary, however, the file data appears to follow  
immediately after the inode header, and hence this won't be aligned  
on a page boundary (4 Kbytes).   Due to this you cannot use the  
generic read page function (block_read_full_page), however, ROMFS has  
this non-alignment issue and you can simply copy what it does.

Hope that helps.

Phillip