lkml.org 
[lkml]   [2002]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH - change to blkdev->queue calling triggers BUG in md.c
On Mon, Sep 02, 2002 at 03:00:27PM -0700, Linus Torvalds wrote:

> > No, my suggested changes would not break a single Linux installation
> > in the world.
>
> .. by making your suggested behaviour not be used. Yes.

Not so pessimistic. We go by small steps.

I think it important to get rid of partition table reading in the kernel.

It (pt reading) is wrong in principle, as we agree already.
But there are also all kinds of practical reasons.

One argument is that our traditional DOS-type partition table will soon
be at the end of its useful life. Yes, maybe it survives a few more years
but our own stability requires slow changes, so we must start thinking a
long time in advance.
Another argument is that it sometimes takes a *long* time, like several
minutes, especially when this reading triggers hardware bugs.
Another argument is that nobody knows whether there is a partition table.
In the case of ZIP drives there sometimes is a jumper or special SCSI command
to switch between the "large floppy" and "removable disk" statuses, and
the kernel doesnt know.
Another argument is that tricky things happen in the presence of disk managers.

So stage one is a kernel boot parameter "nopt" or so, that stops parsing
of partition tables other than the root partition. Some people need it
because of special problems, others just want to experiment. That is good,
and we'll get some feedback on partx and family.

Stage two happens a year later, when we have a working initrd. Seen from the
outside the new (kernel + initrd) plays the role of the old kernel.
Ha. That means that we can move the pt reading to initrd, and nobody notices.

Stage three happens when initrd and kernel no longer are so tightly coupled.
Initrd is just early userspace, tools exist to populate it, distributions make
their own. Now the kernel does not need any partition reading code and
nobody ever noticed. And the setup has become much more powerful.

-----

> But if that is the case, then we _still_ need to fix the media change and
> partition read issue. Right? Which brings back _all_ my points for why it
> should be done at open time, and by the generic routine. Agreed?

The above was mainly about the partition reading at boot time.
There are two other situations: partition reading at insmod time,
and partition reading at media change time.

But these are easier situations. There is a functioning userspace already.
As I said, in view of the desired direction, I would not mind at all if
a media change did not trigger partition reading today.
(In fact, for me, under 2.5.33, it doesn't. But blockdev --rereadpt helps.)


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

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.049 / U:4.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site