Re: Amiga RDB

> > Is Amiga still used in Germany?
> 
> Yep, Germany is so backwards, most people are still using C64s and
> Amigas. ;-))
> 
> I believe, Amigas are at least mostly disappeared from business. 
> Though
> three years or so ago, when Stippi and I started with eXposer, Take2
> (on Amiga) was still a very popular line testing program. But I think,
> aside from those obscure applications only hardcore fans still use the
> Amiga. Mostly gathered around the companies producing (or promising)
> Amiga successor products. Nevertheless, according to what can be read
> on OSNews from time to time, the community seems to be much greater
> than the BeOS community.

Interesting. It still sounds like Amiga had a much greater presence in 
Germany than in the US. I've at least seen C64s... :-)

> > > > > I'm a bit uncertain, whether I start to dislike the
> > > > > BPartitionableSpace
> > > > > objects. In the case of this partitioning system they would
> > > > > certainly
> > > > > respect the reserved space attached to the partitions and thus
> > > > > make
> > > > > DriveSetup think, that the partitions can't be moved only a
> > > > > short
> > > > > distance, as that would invade non-partitionable space.
> > > > 
> > > > That reserved space would have to belong to the partition 
> > > > itself,
> > > > I
> > > > think. But if you start to dislike the BPartitionableSpace
> > > > objects,
> > > > I
> > > > can't stop you ;-)
> > > 
> > > Hehe. I'm still waiting for a plea from Tyler to keep them. :-P
> > 
> > If anyone has a better idea, I'm willing to hear it out. :-P :-)
> >
> > Why not make the non-reserved space a virtual sub-partition of the
> > actual partition? Then you could still move the entire partition
> > around, reserved space and all, while respecting the reservations.
> 
> That would be a solution only, if the partition in question
> accommodates subpartitions, what, according to Axel, the RDB doesn't
> natively support (we would provide nesting of partitioning systems
> though). In case of a file system to me it doesn't seem to work very
> well, for we would then have both, subpartitions and a file system. We
> couldn't simply publish the whole partition as a device.

I'm not sure I see where the problem is coming from. The file system 
would then live in the virtual sub-partition, which does not really 
exist on the physical hardware, but is implemented solely in the 
disk_device_manager add-ons. I.e., when an RDB partition with reserved 
space is discovered, that partition would publish a virtual child 
partition of the appropriate, non-reserved size, and disallow 
allocation of any of the reserved space for anything else.

> A similar problem occurs when we explicitly support reserved blocks at
> the beginning and end of a partition in the API. Although then we can
> at least be sure that there won't be a reserved subpartition in the
> middle of a partition. The ugliness with the publishing of the device
> could be solved by having the reserved space live before/after and not
> at the beginning/end of the partition. But then the handling of child
> partitions becomes less nice.

Again, if you just use a nested (but fake) child partition, there's no 
need to publish the entire partition. Just publish the virtual, 
non-reserved space as a device. It's still just a contiguous chunk of 
space on the device, so I don't see where any ugliness would come from.

> But rather than wasting another 16 bytes per partition, I'd like to
> ignore those reserved blocks in the API and hope that this feature is
> virtually unused. The partition module would take care, that no bad
> things happen in cases where it is used, and DriveSetup would 
> visualize
> such a setting slightly suboptimal. Well, and BPartitionableSpaces
> would suck...

I think I'm okay with this, too, but I think the virtual partition idea 
is cleaner (at least, until you somehow convince me it won't work. :-)

> Maybe it's a good idea to remove them from the BPartition anyway. Mind
> you, resizing/moving a partition will also always affect sibling
> partitionable spaces (up to four in case of moving), which might be a
> bit hairy to handle. Since the information the BPartitionableSpaces
> provide are of interest only, if one is going to modify the partition
> layout (and would only waste resources otherwise), it might make more
> sense to retrieve them on request only. E.g. via a method
> BPartition::GetPartitionableSpaces(BObjectList<BPartitionableSpace> *
> spaces). Or maybe even more consequent:
> BPartition::GetPartitioningInfo(BPartitioningInfo *info), where
> BPartioningInfo could not only know, which are the free spaces, but
> also which space is assigned to which subpartition. This would also
> solve the problem with the RDB's reserved space at the beginning/end 
> of
> partitions, since the BPartitioningInfo would consider the complete
> space occupied by a subpartition.

Well, either idea seems perfectly reasonable to me, particularly given 
the strong distaste everyone seems to have for my lovely 
BPartitionableSpace objects. :-( ;-)

-Tyler