Re: Partitioning context

Tyler Dauwalder <tyler-cyCl/[email protected]>
Newsgroups gmane.os.openbeos.storage
Message-ID <[email protected]>
On 2003-04-06 at 11:28:57 [-0700], Ingo Weinhold wrote:
> 
> "Axel D=F6rfler"  <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.