The NetBSD Project

CVS log for src/sys/fs/msdosfs/msdosfs_vfsops.c

[BACK] Up to [cvs.NetBSD.org] / src / sys / fs / msdosfs

Request diff between arbitrary revisions


Default branch: MAIN
Current tag: matt-nb6-plus


Revision 1.93.6.1 / (download) - annotate - [select for diffs], Thu Jul 5 17:36:31 2012 UTC (11 years, 9 months ago) by riz
Branch: netbsd-6
CVS Tags: netbsd-6-1-RELEASE, netbsd-6-1-RC4, netbsd-6-1-RC3, netbsd-6-1-RC2, netbsd-6-1-RC1, netbsd-6-1-4-RELEASE, netbsd-6-1-3-RELEASE, netbsd-6-1-2-RELEASE, netbsd-6-1-1-RELEASE, netbsd-6-0-RELEASE, netbsd-6-0-RC2, netbsd-6-0-RC1, netbsd-6-0-5-RELEASE, netbsd-6-0-4-RELEASE, netbsd-6-0-3-RELEASE, netbsd-6-0-2-RELEASE, netbsd-6-0-1-RELEASE, matt-nb6-plus-nbase, matt-nb6-plus-base, matt-nb6-plus
Branch point for: netbsd-6-1, netbsd-6-0
Changes since 1.93: +3 -3 lines
Diff to previous 1.93 (colored)

Pull up following revision(s) (requested by tsutsui in ticket #395):
	sys/fs/msdosfs/msdosfs_vfsops.c: revision 1.95
	sys/arch/atari/atari/autoconf.c: revision 1.62
	sys/dev/md.c: revision 1.67
Add a dirty hack for atari's ancient installation ramdisk:
 Forcibly configure md0, md1, and md2 devices before setroot()
 for atari's traditional "auto-load from floppy on open" md_root device
 which loads installation ramdisk image from floppy.
 md(4) has been changed dynamically configured at first open after 5.0
 and md devices won't appear in "root device:" prompt without this hack.
Tested on TT030.
Should be pulled up to netbsd-6.
Make sure that disklabel of md(4) device is initialized
in the case where it's configured in MD md_open_hook().
Without this, msdosfs_mountfs() (which is called from msdosfs_mountroot())
will be called with uninitialized disklabel (d_secsize == 0) and
it gets "panic: buf mem pool index 23" later on atari.
This is because getdisksize() doesn't check returned d_secsize value
and msdosfs_mountfs() blindly calls bread(9) with size==0 in that case.
Should be pulled up to netbsd-6 (at least for atari).
Add a sanity check if secsize returned from getdisksize() isn't bogus.
This prevent possible panic "panic: buf mem pool index 23" later in
vfs_bio.c:buf_mempoolidx().
(I'm not sure if it's okay for getdisksize() to assume that
 partinfo taken from DIOCGPART is properly initialized
 on all disk(9) devices or not)
See also:
http://mail-index.NetBSD.org/source-changes/2012/06/30/msg035298.html

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>