4) moving the call of partition-reading code into do_open() (for cases when
->bd_contains is non-NULL), killing the "set block_device fields by hand"
mess in check_partitions()
Hmm. I probably misunderstand some things.
There must be a data structure with the information that belongs
to a disk, opened or not. The size, the sectorsize, the partitions, ...
The structure that I made kdev_t point at.
What are you working towards? There is a struct block_device.
But it is not permanent. It is created when the device is opened
and disappears when it is closed.
So it doesnt help in replacing kdev_t - the permanent data must still
be somewhere. There is a struct gendisk. That is better.
It is not difficult to make sure that all devices that have array data
also get a struct gendisk.
Then there is struct request_queue. I see that it got hardsect_size,
but it seems a less suitable place for general disk info.
[So, let me repeat: Question: where do you plan to put permanent
Now about this partition-reading code. It requires a partitiontable type,
just like mounting requires a filesystem type. Now mount() has a
parameter that specifies the filesystem type. But open() does not
have a parameter that specifies a partitiontable type.
It seems to me that doing partitiontable reading in do_open()
is a really bad idea.
Maybe you have a "do it only once" kludge in mind?
To get something ugly, equivalent to the present situation?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/