> You are right but the fact is right now we have to do it this way.
That is OK - I just write to make sure we all agree that this must
only be an intermediate stage. Scanning for partitions must not be
something obscure that happens deep down in some driver.
>> You should offer the list of disks seen to user space, and user space
>> should decide which disks have to be investigated, and tell the kernel
>> about the partitions it wants to have on these disks.
>> That way all knowledge about partitioning, dynamic disks, disk managers
>> and the like is removed from the kernel, and moved into partx-type code.
> But there is one thing, which isn't prette about the above sheme: races
> and atomicity of operations... Well this could be solved
> by making the mount system call passing this information as a parameters.
> You wouldn't even need to pass any list of disks to user land - we don't
> do it right now.
You see, some disks belong to RAIDs, some disks are in reality very
slow objects, like compact flash cards or so, some disk have some foreign
partitioning scheme. There can be all kinds of reasons why we do not
want to start reading and interpreting any random disk-like device.
I know that we used to do this, but it was wrong, so we must slowly move
to a setup where we do no longer do this.
So, user space is started on a ramdisk or so, and gets parameters
rootdev=, rootpttype=, rootpartition=, rootfstype=.
Now it can use rootpttype to scan rootdev, find the partitions,
find rootpartition, mount it as type rootfstype on /.
Afterwards the existence of more devices, possibly with partitions,
becomes of interest, for example because there is a "mount -a" somewhere.
Here userspace needs a list of available devices. Maybe /proc/partitions.
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/