FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API 2.x, Kernelland Draft

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Sun, 08 Jun 2003 21:49:26 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
[...]
> > > commit_disk_device_modifications(device, ...);
> > >     // this will finally trigger the modifications to be made
> > >     // and unlock the API - or will it first process all jobs
> > >     // and the unlock the API?
> > 
> > It will compare the original with the shadow hierarchy and create 
> > and
> > schedule the jobs needed to transform the original hierarchy
> > respectively. The shadow hierarchy is deleted, and all partitions 
> > that
> > might be affected by any scheduled job are marked `busy', all 
> > ancestors
> > of `busy' partitions are marked `descendant-busy'. When the syscall
> > returns, a subsequent prepare_disk_device_modifications() on that 
> > disk
> > device will succeed -- only partitions that are not marked `*busy' 
> > are
> > allowed to be modified then, though.
> > 
> > > Where do we need the shadow partition name anyway? It doesn't 
> > > seem 
> > > to
> > > be part of the user API.
> > 
> > You mean KPartition::Name()? If one sets the name of a partition 
> > via
> > the userland API, it should also be reflected in the partition 
> > data, I
> > think. We currently don't have the functionality to set the name of 
> > a
> > partition in the userland API. We may want to add it, though. Maybe 
> > we
> > also want to discriminate between Name() and ContentName() (e.g.
> > partition name vs. FS/volume name).
> 
> Yes, we probably should allow both, since they both have accessors 
> already.

OK.

> > > So the user will never
> > > come across all those user_ prefixes - because if he would, I 
> > > would
> > > consider dumping them.
> > 
> > I introduced the prefix for partition_data and disk_device_data,
> > because there're equally named structures for the partition module/
> > FS
> > add-on interfaces and KPartition/KDiskDevice will probably have to 
> > deal
> > with both. For consistency I added he prefix to the other userland
> > structures as well.
> > 
> > > And if we have all these int32 IDs we could think about adding a 
> > > new
> > > type for them, like partition_id.
> > 
> > Good idea. What about IDs for disk systems and disk device jobs?
> > disk_system_id, disk_device_job_id? Too long?
> 
> How about disk_job_id? Or just job_id, unless you're worried that's 
> too 
> general.

job_id is a bit too general, I think. disk_job_id works for me, though.

> > > We might also add a "name" field to initialize_partition() since
> > > almost
> > > all disk systems share this property (IIRC only Intel style
> > > partitioning doesn't have it).
> > 
> > If we do that, we should also make the functionality to set the 
> > name
> > explicit (or even `name' and `content name').
> 
> Might be a good idea, since it's a pretty ubiquitous concept. And 
> particularly since Tracker lets you do this by just renaming a 
> volume.

OK, will be done.

[...]
> > > > > > It could be nice to have this, and it would also be a bit
> > > > > > faster.
> > > > > > I
> > > > > > am not sure if it's rendering the API inconsistent there,
> > > > > > though.
> > > > > > One
> > > > > > could argue that the partition related functions (not
> > > > > > initialize())
> > > > > > are a bit separated from the rest anyway.
> > > > > Either way would work for me. So, if you have any 
> > > > > preferences...
> > > > I prefer passing the device. :-)
> > > 
> > > Okay, so let's do that, then :-)
> > 
> > So, then it's a FD plus the ID of the partition (something is 
> > needed 
> > to
> > identify it), I suppose.
> 
> Yes to the former, and yes to the latter where it's needed (the 
> scanning functions could get away with the the FD, as the partition 
> scanning functions do, couldn't they?).

Yes, since the supplied partition_data already contains some 
information, among them the ID.
First I intended to pass a FD for the `raw' device (also for the 
scanning functions), but meanwhile I favor to pass a FD for the virtual 
device published for the partition. It seems much more convenient, 
especially for most file systems. If some disk system needs access to 
the `raw' device, it can still get its path and open it on its own.

I will go ahead and incorporate the changes discussed into both the 
kernelland and userland headers, start implementing a minimal disk 
device manager (i.e. basic KPartition, KDiskDevice, KDiskDeviceManager, 
the scanning part of KDiskSystem and KPartitioningSystem), and will 
adjust the intel partitioning module to the new interface, so that 
scanning should work.

Regarding the file system part, I'm not sure how to handle that. I 
think, as long as we're developing in userland having separate modules 
is the way to go.

CU, Ingo