From: Andries.Brouwer@cwi.nl
To: aebr@win.tue.nl, torvalds@transmeta.com
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, neilb@cse.unsw.edu.au
Subject: Re: PATCH - change to blkdev->queue calling triggers BUG in md.c
Date: Mon, 2 Sep 2002 23:27:03 +0200 (MEST) [thread overview]
Message-ID: <UTC200209022127.g82LR3g12738.aeb@smtp.cwi.nl> (raw)
> But I hope he makes precisely this: a kernel that does not do any
> partition reading of its own.
I disagree, if only because of backwards compatibility issues.
On a conceptual level I think you're right. However, it will break too
many standard installations as is.
If/when we have a reasonable initrd setup that is usable, we could do some
automatic partitioning of devices that are available at bootup to minimize
the impact, but I don't think it is realistic otherwise.
Compare it with mounting.
It would be very bad if the kernel automatically mounted all
filesystems in sight. So, user space tells what to mount.
But at boot time there is a special situation.
In the end we want to have an initrd that mounts the rootfs,
but today we give kernel command line parameters with
rootfstype= and root=.
In a similar way it is bad that the kernel automatically tries
to interpret some data on a block device as a partition table.
The user can tell the kernel. (Yes, today.)
But at boot time there is a special situation.
In the end we want to have an initrd that does the partition reading,
but now we could give a kernel command line parameter with
rootpttype= and have the kernel only parse the partition table
of the root device.
Andries
[Yes, a shock, but very easy for people to add
blockdev --rereadpt /dev/foo
(or a partx call) in some bootscripts.]
[Don't think that I actually propose doing this today as the default,
but it would be a very small patch to add this as an optional
behaviour. But there is today, and there is the faraway goal.
The faraway goal is: no partition table reading in the kernel.
And that influences designing today what to do on media change.
Already today I would consider it entirely reasonable if there
was no automatic partition table reading after a media change.]
next reply other threads:[~2002-09-02 21:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-02 21:27 Andries.Brouwer [this message]
2002-09-02 21:39 ` Linus Torvalds
2002-09-02 21:48 ` Thunder from the hill
2002-09-02 21:43 ` Thunder from the hill
2002-09-02 21:58 ` Andries Brouwer
2002-09-02 22:06 ` Linus Torvalds
2002-09-02 22:39 ` Thunder from the hill
2002-09-02 22:33 ` Hacksaw
2002-09-02 22:57 ` Oliver Neukum
2002-09-02 23:27 ` Hacksaw
2002-09-03 17:23 ` Thunder from the hill
2002-09-03 18:04 ` Hacksaw
2002-09-03 19:38 ` Thunder from the hill
2002-09-03 20:20 ` Hacksaw
2002-09-03 20:34 ` Thunder from the hill
2002-09-03 20:45 ` Alan Cox
2002-09-03 20:55 ` Thunder from the hill
2002-09-03 21:59 ` Alan Cox
2002-09-03 22:03 ` Thunder from the hill
2002-09-04 0:08 ` Oliver Neukum
2002-09-04 5:50 ` Thunder from the hill
2002-09-03 20:50 ` Hacksaw
2002-09-03 21:05 ` Thunder from the hill
2002-09-03 21:32 ` Hacksaw
2002-09-03 21:51 ` Thunder from the hill
2002-09-04 8:02 ` Giuliano Pochini
-- strict thread matches above, loose matches on Subject: below --
2002-09-03 0:53 Andries.Brouwer
2002-09-03 3:55 ` Linus Torvalds
2002-09-03 4:06 ` Linus Torvalds
2002-09-03 15:22 ` Andries Brouwer
2002-09-02 21:41 Andries.Brouwer
2002-09-02 22:00 ` Linus Torvalds
2002-09-02 23:08 ` Andries Brouwer
2002-09-02 23:27 ` Linus Torvalds
2002-09-02 8:53 Andries.Brouwer
2002-09-02 17:01 ` Linus Torvalds
2002-09-02 20:35 ` Andries Brouwer
2002-09-02 20:50 ` Linus Torvalds
2002-09-01 23:43 Neil Brown
2002-09-02 4:13 ` Linus Torvalds
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=UTC200209022127.g82LR3g12738.aeb@smtp.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=torvalds@transmeta.com \
/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
all inboxes | Powered by JetHome®