Re: [Re: How to add ntfs support]

Re: [Re: How to add ntfs support]

[Blesson Paul]

Hi Anton
              So you are constructing a improved NTFS file driver. So when you
have to check your written codes of file driver, will u recompile the whole
kernel ? . That is what I am asking. I am in a way to build a new file system.
I took NTFS as a sample one. I thought , I will first try to compile and make
it run. 
Thanks in advance
                        by
                           Blesson Paul


Anton Altaparmakov <aia21@cam.ac.uk> wrote:
At 09:20 24/05/2001, Blesson Paul wrote:
>      I have redhat6.2. I have to add ntfs support to it(defaultly
>    it do not have). I know to do it by changing the configuration and
>    recompiling the whole kernel. I want to know , is there any method to
>register ntfs file system without recompiling the whole kernel

No, it is not possible to not recompile the kernel if NTFS was configured. 
You might see some very strange effects if you try... What is your problem? 
Just recompile the kernel. Remember NTFS should be used read-only as write 
support is broken.

I have a much improved NTFS driver but my Sourceforge linux-NTFS CVS is 
down (for a week now!) so I can't release it at the moment. )-:

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

Re: [Re: How to add NTFS support]

[Anton Altaparmakov]

Hi,

At 05:40 25/05/2001, Blesson Paul wrote:
>So you are constructing a improved NTFS file driver. So when you have to 
>check your written codes of file driver, will u recompile the whole kernel 
>? . That is what I am asking. I am in a way to build a new file system.
>I took NTFS as a sample one. I thought , I will first try to compile and make
>it run.

NTFS is not a good example for a 2.4.x file system at the moment IMHO. It 
doesn't even use the page cache at all...

But anyway, I recompile the whole kernel the first time round, i.e. say I 
install the latest kernel, apply my latest NTFS patch, copy my old .config 
to linux/.config, make oldconfig. Then I set off: make dep && make bzImage 
&& make modules && sudo make modules_install [switch to different VT and do 
other stuff, go out, have dinner, whatever...], then install kernel, lilo, 
reboot.

Once I am running the new kernel, it becomes much easier: modify some code 
in linux/fs/ntfs, then from linux/ I just do: make modules && make 
modules_install && rmmod ntfs && modprobe ntfs and the new driver is loaded...

If I change any code outside of fs/ntfs then a new make bzImage, etc is 
required, as I build everything static (only ntfs as a module).

If I install a new kernel as I do quite frequently to keep up on what's 
going on, a new kernel compile is required from scratch...

Hope this helps.

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Re: How to add ntfs support]

[David Woodhouse]

blessonpaul@usa.net said:
>               So you are constructing a improved NTFS file driver. So
> when you have to check your written codes of file driver, will u
> recompile the whole kernel ? . That is what I am asking. I am in a way
> to build a new file system.

In general, it is not necessary to rebuild the kernel when you enable and
compile (or indeed write) a new module.

Places where the code in the kernel itself actually depends on the value of
CONFIG_blah_MODULE are thankfully relatively rare, although this ugliness
does happen at times. The filesystem code is fairly sane in this respect,
though, so you shouldn't have problems.

The main thing you have to watch when loading a new filesystem is the size 
of the inode and superblock unions. If you are adding your 
shinynewfs_inode_info to the inode union, and it's _larger_ than the 
previous size of the inode union, then you would have to recompile the 
kernel (or allocate it separately, which you're probably going to have to 
do in 2.5 anyway).

Note that this isn't particularly likely to be a problem - the inode union
has space for _all_ the filesystems, not just the ones you said 'y' or 'm'
to, and some of them are quite large. But it's worth checking.

Most of the JFFS2 development was done without recompiling kernels. I 
didn't even touch the kernel build tree - just
	make -C /usr/src/linux SUBDIRS=`pwd` modules

For safety, I put the following in the module init routine during development:

#ifdef JFFS2_OUT_OF_KERNEL
        /* sanity checks. Could we do these at compile time? */
        if (sizeof(struct jffs2_sb_info) > sizeof (((struct super_block *)NULL)->u)) {
                printk(KERN_ERR "JFFS2 error: struct jffs2_sb_info (%d bytes) doesn't fit in the super_block union (%d bytes)\n", 
                       sizeof(struct jffs2_sb_info), sizeof (((struct super_block *)NULL)->u));
                return -EIO;
        }

        if (sizeof(struct jffs2_inode_info) > sizeof (((struct inode *)NULL)->u)) {
                printk(KERN_ERR "JFFS2 error: struct jffs2_inode_info (%d bytes) doesn't fit in the inode union (%d bytes)\n", 
                       sizeof(struct jffs2_inode_info), sizeof (((struct inode *)NULL)->u));
                return -EIO;
        }
#endif


--
dwmw2