From: David Woodhouse <dwmw2@infradead.org>
To: Blesson Paul <blessonpaul@usa.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Re: How to add ntfs support]
Date: Sat, 26 May 2001 10:25:01 +0100 [thread overview]
Message-ID: <23383.990869101@redhat.com> (raw)
In-Reply-To: <20010525044008.14212.qmail@nwcst284.netaddress.usa.net>
In-Reply-To: <20010525044008.14212.qmail@nwcst284.netaddress.usa.net>
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
prev parent reply other threads:[~2001-05-26 9:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-25 4:40 [Re: How to add ntfs support] Blesson Paul
2001-05-25 8:47 ` [Re: How to add NTFS support] Anton Altaparmakov
2001-05-26 9:25 ` David Woodhouse [this message]
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=23383.990869101@redhat.com \
--to=dwmw2@infradead.org \
--cc=blessonpaul@usa.net \
--cc=linux-kernel@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