Re: ddm interface for Intel partitioning system

On 2007-05-17 at 18:36:33 [+0200], Tomáš Kučera <[email protected]> wrote:
> I am going to implement writing support to the Intel partitioning system. I 
> read
> some previous emails regarding this topic but I am not sure whether I 
> understand
> to all functions of the interface well. So I wrote documentation first (how 
> I
> think it should work), it is just here:
> http://www.mastercode.eu/haiku/doc/ddm__modules_8h.html
> source to the documentation is here:
> http://www.mastercode.eu/haiku/doc/ddm_modules.dox
> I could misunderstand meaning of some functions so please contact me if
> something is not right.
> 
> Especially with these functions (typedefs) I wasn't too sure:
> partition_supports_moving

This is actually only used for the unlikely case of nested partitioning 
systems. E.g. assume you have a standard PC with Intel style partitioning. 
You run some obscure OS for which an emulator exists (maybe Linux with 
VMWare). This emulator supports to use a partition as a disk for its guest 
OS. This disk (i.e. the partition) would be partitioned with some 
partitioning system, say Apple style, thus resulting in a nested partitioning 
system.

Haiku will be able to auto-recognize this nesting and the partitions defined 
by the inner (Apple) partitioning system and should be able to move the 
partition containing the Apple style partitioned partition. To verify whether 
this partition can be moved, the disk device manager will invoke (a) the 
partition_supports_moving_child() hook of the Intel partitioning system with 
the partition in question as child partition parameter, and (b) the 
partition_supports_moving() hook of the Apple partitioning system. As most 
partitioning systems the Apple partitioning system is agnostic about its 
environment and thus doesn't have to do anything when the parent partitioning 
system moves the partition (including its content) -- it will just work after 
having been moved. Hence the hook should return true (for moving is 
supported) and true for "isNoOp" (nothing has to be done, i.e. there won't be 
a partition_move() hook).

The hook will mostly be relevant for partitioning systems that themselves 
support nesting partitions. In fact the way we map the Intel style 
partitioning we actually have two levels of partitioning systems: The 
partition map at the top level potentially containing an extended partition 
(which in turn contains logical partitions). IIRC the offsets of the logical 
partitions are relative to the offset of the extended partition, so this hook 
won't be need in this case either.

> partition_supports_initializing

The initial sentence of the description fits. I don't quite understand what 
"partition is possible to initialize only to the type represented by this 
module." is supposed to mean. If a partition is given, this hook returns 
whether the partition can be formatted with this partitioning system. This 
should work with most partitioning systems, if initialization is supported at 
all. An exception is the Intel system for instance. The module responsible 
for extended partitions cannot initialize anything but what the parent 
partitioning system (partition map) has marked an extended partition.

If no partition is given, the question to answer is only if the partitioning 
system supports initialization at all. This holds analoguously for all of the 
partition_supports_*() hooks, IIRC.

> partition_supports_initializing_child

This hooks checks whether it is possible that the child partition can be 
initialized with the given disk system (partitioning or file system). E.g. 
you can't initialize an extended partition with anything but the partitioning 
system managing extended partitions.

> partition_is_sub_system_for

Your description is not correct. The question the hook answers is very 
specific and has to be with true nesting of partitioning systems. A sub 
(partitioning) system is one that would naturally live on a child partition 
of another partition system. E.g. the partitioning system for intel extended 
partitions lives naturally (only) in a child partition of a partition 
governed by the Intel partition map partitioning system. In that way, 
although there can be two levels of partitions (-> extended -> logical), this 
is no true nesting of different partitioning systems (unlike e.g. an Apple 
partitioning system living in a primary Intel partition). I.e. if the hook is 
invoked for the Intel extended partition partitioning system given a Intel 
partition map partition, it would return true, while pretty much every other 
combination (at least all I can imagine ATM) would result in a return value 
of false.

The reason why this hook exists at all is that it might be handy in a 
partition manager application. Usually true partition system nesting is not 
supported by other operating systems, so that the application should 
preferrably present the obvious choices.

> partition_validate_move

As you describe, the hook checks whether from the point of view of the 
partition system living in the given partition, the partition can be moved to 
the given offset, and adjusts the offset to the next feasible value. As 
explained above for partition_supports_moving() hook this hook usually won't 
do anything (i.e. return true and leave the offset unchanged).

> partition_validate_resize

Similar to moving. The perspective is the one from the partitioning system 
inhabitating the given partition. This hook is a little more likely to do 
anything. The partition system might require a certain size alignment for 
instance.

> partition_validate_set_parameters
> partition_validate_set_content_parameters

The "parameters" of a partition are special parameters the parent 
partitioning system associates with the partition. E.g. the Intel 
partitioning system knows an "active" flag that can be set or not set for 
each of the defined partitions.

The "content parameters" of a partition are special parameters the 
partitioning system living in the partition associates with it. E.g. the 
Amigar RDB system seems to have certain flags and IDs that can be set for the 
partitioning system.

> partition_get_type_for_content_type

Most partitioning systems can specify a type value/string for the partitions 
they define. In case of the Intel partitioning system it's a one byte ID. Our 
generic API requires a string representation. The content type of a partition 
is the name of the disk system (partitioning or file system) the partition is 
initialized with; those names are standardized in Haiku (see 
headers/private/storation/DiskDeviceTypes.h) Given a content type, this hook 
of the partitioning system returns the type that best corresponds to it. E.g. 
for a content type of "Be File System" the Intel partitioning system would 
return a type string that it associates with the byte value 0xeb. Currently 
that type string is "BFS Filesystem" (admittedly somewhat clumsy). There are 
no other constraints to the type string than being human readable and the 
partitioning system being able to translate it to its internal representation 
and back.

> partition_shadow_changed

Your description is correct. Often this hook will be a no-op, but it allows 
the partitioning system to adjust the supplied partition_data structure, if 
necessary. E.g. say resizing the partition requires adjustments of certain 
other parameters (e.g. the block size or some special parameter), that's when 
the partitioning system can perform them.

> partition_resize
> partition_move

I hope my above explanations already clarify the underlying ideas. BTW, 
partition_move() is called after the partition_move_child() hook for the 
parent partitioning system has been called. If the partition grows 
partition_resize() is called after the parent partitioning system's 
partition_resize_child(), if it shrinks the other way around.

Hope that helps.

CU, Ingo

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Open-beos-kernel-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel