The point about backwards compatibility is that things WORK.
Must I conclude that you did not read my entire letter?
Since we started this small detour talking about media change,
let me quote that fragment once more.
"[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.]"
No, my suggested changes would not break a single Linux installation
in the world.
Andries
On Mon, 2 Sep 2002 Andries.Brouwer@cwi.nl wrote:
No, my suggested changes would not break a single Linux installation
in the world.
.. by making your suggested behaviour not be used. Yes.
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?
Linus
On Mon, Sep 02, 2002 at 03:00:27PM -0700, Linus Torvalds wrote:
quoted
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
On Tue, 3 Sep 2002, Andries Brouwer wrote:
I think it important to get rid of partition table reading in the kernel.
Why?
It (pt reading) is wrong in principle, as we agree already.
No, we don't agree.
I see that some people would like to remove it from the kernel, and I'm
not violently opposed to it if it can be done without breaking existing
behaviour.
But I do _not_ see any really fundamental reason why the kernel shouldn't
parse the partition tables. I see a lot of problems if the kernel were to
stop, and I don't see a lot of advantages to not doing so.
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.
That's a bad argument. It's not as if we want to have random formats for
this thing. Partitioning is damn important, and it has to be portable
across different machines and different operating systems. That all means
that there is absolutely _zero_ incentive to make up a partition format of
our own, since there are perfectly fine and existing formats.
Another argument is that it sometimes takes a *long* time, like several
minutes, especially when this reading triggers hardware bugs.
This is only an argument for doing it on demand, not for dropping it.
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.
And none of these work any better in user space.
quoted
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.
You seem to think that kernel space somehow cannot do something that user
space can. I just don't see the overriding problems you claim.
Linus