lkml.org 
[lkml]   [2000]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch-2.4.0-test13-pre3] rootfs boot param. support
    On Mon, 18 Dec 2000, Peter Samuelson wrote:

    >
    > [Tigran Aivazian]
    > > no, because it would cause a "spurious" call to get_fs_type("") which
    > > we don't want to happen (by default i.e. -- if user _really_ wants it
    > > that is ok). The default of "ext2" is fine.
    >
    > I still disagree -- super.c is no place to dictate the default root
    > filesystem. And I agree with Andries that 'rootfs=' is confusing.

    I have already covered both of these issues in the email I sent ages
    ago... Here it is below (instead of re-sending) (the original got lost
    because of the mail-abuse vs btconnect's randomness)

    From tigran@veritas.com Mon Dec 18 15:20:08 2000
    Date: Mon, 18 Dec 2000 14:44:32 +0000 (GMT)
    From: Tigran Aivazian <tigran@veritas.com>
    To: Andries.Brouwer@cwi.nl
    Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
    Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support

    On Mon, 18 Dec 2000 Andries.Brouwer@cwi.nl wrote:
    > (i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
    > It gives some property of the root filesystem, but which?

    No, it is not ambiguous. Because, look at this sequence:

    "ffs", "ufs", "bfs", "reiserfs", "vxfs", "sockfs", "pipefs", "nfs", ...

    they are familiar to everyone and everyone immediately recognizes the
    attribute they describe by the ending "fs". So, the attribute is
    immediately obvious and should be recognized by programmer without need to
    explicitly comment about it (it just is like it is _obvious_ that static
    int x; is initialized to 0 and there is no need to start asking oneself
    "what is this attribute of x that is being set to 0 here... ah.. it's the
    _value_ thereof!" )

    > +static char rootfs[128] __initdata = "ext2";
    >
    > (ii) It is a bad idea to arbitrarily select "ext2".

    No, how could you say it is a bad idea without saying also _what_ is a
    good idea? If there is no replacement for a bad idea then it is, by
    definition, a good (or best) idea. So, having not found a better initial
    value for rootfs[] I set it to "ext2". Setting it to "" is no good as I
    explained to Peter. Setting it to NULL is also no good because needs an
    extra line of code in mount_root() to check for it. So, what then? I say
    "ext2" as it is the most popular Linux filesystem at the moment.

    > (iii) I probably give the rootfstype explicitly because bad things
    > (like disk corruption) happen when the kernel misrecognizes some
    > filesystem, and perhaps starts updating access times or so.
    > Thus, if the boot option rootfstype is given, I prefer a boot failure
    > over a kernel attempt to try all filesystems it knows about, just like
    > mount(8) only will start guessing when no explicit type was given.

    that gives it a different semantics, i.e. you are changing the rules. I am
    not sure which rules are better but there are advantages to it being as
    is, e.g. one could hardcode "rootfs=vxfs" in their lilo.conf and rely on
    fallback to ext2 for some of the partitions but not others.

    This one is a matter of taste and if Linus says your way is better I will
    redo the patch immediately. Both ways are fine with me.

    Regards,
    Tigran

    From tigran@veritas.com Mon Dec 18 15:20:13 2000
    Date: Mon, 18 Dec 2000 14:54:40 +0000 (GMT)
    From: Tigran Aivazian <tigran@veritas.com>
    To: Andries.Brouwer@cwi.nl
    Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
    Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support

    On Mon, 18 Dec 2000, Tigran Aivazian wrote:
    > Setting it to NULL is also no good because needs an
    > extra line of code in mount_root() to check for it.

    before N people misunderstand the above -- I meant having just a
    pointer and doing kmalloc/kfree manually.

    Regards,
    Tigran




    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:0.045 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site