From: GOTO Masanori <gotom@debian.or.jp>
To: Andries.Brouwer@cwi.nl
Cc: torvalds@osdl.org, akpm@osdl.org, gotom@debian.or.jp,
linux-kernel@vger.kernel.org
Subject: Re: [uPATCH] refuse plain ufs mount
Date: Tue, 27 Jan 2004 14:04:55 +0900 [thread overview]
Message-ID: <81fze29e2w.wl@omega.webmasters.gr.jp> (raw)
In-Reply-To: <UTC200401270407.i0R47oi29367.aeb@smtp.cwi.nl>
At Tue, 27 Jan 2004 05:07:50 +0100 (MET),
Andries.Brouwer@cwi.nl wrote:
> From: Linus Torvalds <torvalds@osdl.org>
>
> > But you see, it wasn't the user at all, and it wasn't a ufs filesystem.
> > It is kernel probing that causes error messages. That is unwanted.
> > So, your version is wrong.
>
> Yes.
>
> However, I think the _real_ bug is that we have reiserfs near the tail of
> filesystems to try.
>
> Can you test that alternate patch instead?
>
> Funny how we alternate - when I choose the pure, theoretical point of view
> you prefer practice, when I prefer practice you become pure.
>
> This time you prefer practice: the list of filesystems is full of garbage
> and good filesystems should be near the top.
> I prefer theory: the kernel should not probe at all, so everybody who
> forgets rootfstype= gets what he deserves.
>
> Be that as it may - below a patch as I suppose you had in mind.
> I don't like it very much. Ordering constraints in makefiles are bad.
>From the user point of view, I think it's weilcome that "popular"
filesystems like reiserfs used for rootfs is moved upwards, because
boot up speed is accelerated. It's difficult to define what "popular"
is, but apparently hugetlbfs should be lower than reiserfs. So your
patch seems fine, I think.
> Have not compiled or tested.
> You can apply it I suppose, but after doing so my earlier patch is still
> meaningful. Maybe you should also apply that (and the Doc update).
I misunderstand what the real problem is.
The problem as you previously wrote was that UFS does not use
ufs_fill_super third argument "silent" value, so some warning messages
are scattered during boot up time. I agree that this is exactly just
a noise. Andries removed those warnings instead of using "silent",
but in fact such messages are important for users who want to mount
ufs filesystem to tell for kernel the proper UFS type. To be honest,
I sometimes forget to add "ufstype=" option to mount UFS, so this
warning is useful for me. I attached patch which uses "silent" value
for this problem. I checked this patch which removes all scattered
UFS messages from boot up screen. I think this one is acceptable for
even Andries instead of your UFS patch, is it OK?
Regards,
-- gotom
--- fs/ufs/super.c.org 2003-10-20 12:50:24.000000000 +0900
+++ fs/ufs/super.c 2004-01-27 13:26:05.000000000 +0900
@@ -516,7 +516,7 @@
printk("wrong mount options\n");
goto failed;
}
- if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE)) {
+ if (!(sbi->s_mount_opt & UFS_MOUNT_UFSTYPE) && !silent) {
printk("You didn't specify the type of your ufs filesystem\n\n"
"mount -t ufs -o ufstype="
"sun|sunx86|44bsd|old|hp|nextstep|netxstep-cd|openstep ...\n\n"
@@ -575,7 +575,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=old is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -589,7 +589,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=nextstep is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -603,7 +603,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=nextstep-cd is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -617,7 +617,7 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_44BSD | UFS_UID_44BSD | UFS_ST_44BSD | UFS_CG_44BSD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=openstep is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
@@ -631,13 +631,14 @@
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_OLD | UFS_CG_OLD;
- if (!(sb->s_flags & MS_RDONLY)) {
+ if (!(sb->s_flags & MS_RDONLY) && !silent) {
printk(KERN_INFO "ufstype=hp is supported read-only\n");
sb->s_flags |= MS_RDONLY;
}
break;
default:
- printk("unknown ufstype\n");
+ if (!silent)
+ printk("unknown ufstype\n");
goto failed;
}
@@ -687,7 +688,8 @@
uspi->s_sbbase += 8;
goto again;
}
- printk("ufs_read_super: bad magic number\n");
+ if (!silent)
+ printk("ufs_read_super: bad magic number\n");
goto failed;
magic_found:
next prev parent reply other threads:[~2004-01-27 5:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-27 4:07 [uPATCH] refuse plain ufs mount Andries.Brouwer
2004-01-27 5:04 ` GOTO Masanori [this message]
2004-01-27 6:15 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2004-01-28 22:24 Example
2004-01-29 0:13 ` GOTO Masanori
2004-01-27 1:56 Andries.Brouwer
2004-01-27 2:09 ` Linus Torvalds
2004-01-25 0:17 Andries.Brouwer
2004-01-27 1:43 ` GOTO Masanori
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=81fze29e2w.wl@omega.webmasters.gr.jp \
--to=gotom@debian.or.jp \
--cc=Andries.Brouwer@cwi.nl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.