[openbeosstorage] Re: Partitioning context

On 2003-04-06 at 11:28:57 [-0700], Ingo Weinhold wrote:
> 
> "Axel D=F6rfler"  <axeld@xxxxxxxxxxxxxxxx> wrote:
> > 
> > I've just two more (related) points to consider:
> > 
> > - we should probably add an option to recognize files as a hard disk
> > and be able to scan the partitions contained therein
> 
> I already thought about that some months ago, when we were designing
> the previous API. The issue I see is, where the devices are published.
> I would imagine it to work like this: There are syscalls to
> (un)register a file as virtual disk. On registration a device is
> published under 
> /dev/disk/virtual/file/<filename>[uniqueness=5FID]/raw.
> The rest can work completely transparent for the 
> disk=5Fdevice=5Fmanager.
> 
> > - it would be nice if we would recognize if one partitioning system
> > is
> > used inside of another
> 
> As I understand it, that is already built into the DiskDevice 2.x API.
> I'm actually afraid, the current version handles this too
> transparently, since, unless I missed something, there is no way to
> find out, if you have indeed nesting partitioning systems or just a
> single partitioning system supporting hierarchies. E.g. in the intel
> case:
> 
> -----------------------------------------
> |                device                 |
> |---------------------------------------|
> |    1    |    2    |    3    |    4    |
> |---------|-----------------------------|
> | 5  |  6 |                   | 7  |  8 |
> 
> 1 being an extended partition, 4 and 5 contained logical and 2-4, 7,
> and 8 primary ones, the BDiskSystem for device and partitions 1 and 4
> are the same (intel), although 1 and 4 are quite different beasts
> (extended vs. true nesting). (That reminds me, that a
> BPartition::DiskSystem() or better GetDiskSystem() is missing.)

Not quite, I think it would be:

device = (devicetype, intel)
1 = intel extended
2 = filesystem
3 = filesystem
4 = intel
5 = filesystem
6 = filesystem
7 = filesystem
8 = filesystem

Or, using your Type() and ContentType() idea, you'd have:

device = (devicetype -> intel map)
1 = (intel extended partition -> intel extended map)
2 = (intel primary partition -> filesystem)
3 = (intel primary partition -> filesystem)
4 = (intel primary partition -> intel map)
5 = (intel logical partition -> filesystem)
6 = (intel logical partition -> filesystem)
7 = (intel primary partition -> filesystem)
8 = (intel primary partition -> filesystem)

Still, I agree it's difficult to discern by type code alone where 
nesting actually occurs.

> So, probably an additional BPartition::IsLeaf() (better name=3F) 
> would be
> a good idea. It would indicate whether the partition is of a type that
> doesn't allow to create child partitions using the parent's system in 
> a
> non-nesting manner.

For some reason I can't seem to place that isn't sitting right with me. 
How about something more like 
BDiskSystem::SupportsPartitioningSystemNatively(BPartition*, const char 
*system)?

So an intel partition would return true for "intel extended map", but 
false for "intel map". I guess filesystems could trigger a return value 
of true.

> BTW, DriveSetup users should be warned, when they are going to use
> nesting.

Yes. I have no problem allowing it, but they need to know it might not 
work with other OSes (and who knows, maybe it will work, though I kind 
of doubt it... :-)

-Tyler

Other related posts: