Re: DiskDevice API v2.1

"Axel D=F6rfler"  <[email protected]> wrote:
> 
> Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
> > I think in general, the whole device will end up getting locked in 
> > most 
> > cases we'd have now, but with a partitioning system that supported 
> > many 
> > levels of hierarchy (and maybe even with intel extended partitions, 
> > I 
> > don't know... Ingo=3D3F) one could get away with only locking a 
> > portion 
> > of 
> > the drive during a task, and thus let the user muck around with the 
> > rest of it if desired. So it might be useful to support fine 
> > grained 
> > locking. However, is it worth the overhead (1 lock per partition)=3D
> > 3F
> 
> I dunno - if it's easy to implement, then I would say why not. It can 
> only add to the number of features :)

We can still decide that, when we have a clearer picture of the kernel 
part. Even later, for I don't think, it would be that hard to switch 
from device- to partition-based locking or vice versa.

> > > > We just should limit the number of jobs a single partition has
> > > > outstanding (i.e. only one resize change, one movie, etc.).
> > > If requested by a single application, this application should 
> > > bundle
> > > the changes anyway and commit them together. There would never be 
> > > more
> > > than one active or pending job per device or partition.
> > Yes. Multiple changes can be batched, but only one set of 
> > modifications 
> > may be going at any time.
> 
> Okay, that seemed to be a stupid idea :)
> But we should make sure that the user can see which tasks still have 
> to 
> be carried out

We could add methods to BDiskDeviceRoster to provide support for that. 
The typical iteration methods (GetNextActiveJob(BDiskDeviceJob*), 
RewindActiveJobs()) and watching support (StartWatchingJobs(), 
StopWatchingJobs()). BDiskDeviceJob (or better name=3F) would feature 
methods for returning general information about the job, as well as its 
current progress.

>, which are already done, etc. - and that data must 
> survive a crash as well.

Your meta data partition sounds like a very good solution to that.

> [write support in add-ons only]
> > > > To cut a long story short - I still think it makes sense to 
> > > > provide
> > > > complete userland add-ons to implement the functionality found 
> > > > in 
> > > > the
> > > > different partitioning systems.
> > > Oh, that is new. Well, in fact it is old, viz. exactly as in R5. 
> > > I
> 
> No, it wouldn't be the same as in R5 - the kernel couldn't recognize 
> partitions at all.

A bit of partition support for booting must be in the kernel, anyway. 
Or do I miss something=3F It would also be nice, if booting from logical 
partitions was supported.

> > > thought we were agreeing, that a separation of concerns makes 
> > > sense.
> > > I.e. the kernel modules/add-ons would implement the complete read 
> > > and
> > > write access, while the userland add-ons merely provide 
> > > functionality
> > > needed for the GUI.
> > That's what I thought, too. :-)
> > > I actually don't see the benefit of keeping the write support out 
> > > of
> > > the kernel. It seems even more natural to me to let the kernel do 
> > > all
> > > the business, instead of having a userland application notify it 
> > > about
> > > the progress -- that's an unnecessary dependency IMO.
> > I agree.
> 
> Hm, maybe it was a bit too much of a good thing (a small kernel :-).

:-)
Also -- even, if I'm nitpicking here -- most of the functionality would 
be in modules, not in the kernel itself. Not that this means anything 
for the stability of the system. ;-)

> Now, when I think about it, the amount of work that has to be done by 
> the partition modules itself is pretty small. The data move routines 
> doesn't have to be changed for that at all.

Right.

> So I almost agree with you - the only problem I see is that both 
> modules (the kernel and the userland add-on) must be consistent; the 
> kernel module must implement the features the userland add-on 
> promises. 
> That doesn't seem to be too much of a hassle, though.

Exactly. Moreover, according to my current image, the userland add-ons 
would contain very little functionality, only the GUI code for editing 
the system-specific parameters. So, there is very little that needs to 
be consistent.

[...]
> > > > If
> > > > that
> > > > would require absolute blocks, we should go back to the drawing 
> > > > board
> > > > :)
> > > If UDF does, I would vote for omitting support for it out of 
> > > principle
> > > (if necessary, locking Tyler into some basement without 
> > > computers). 
> > > ;-)
> > :-P That's a really bad idea all around. :-)
> > 
> > Seriously, with no UDF support, you have no DVD support. And 
> > iso9660 
> > is 
> > no better, and we sure aren't dropping CD support. How about 
> > BDiskSystem::UsesAbsoluteAddressing()=3D3F
> 
> Wait, wait! Sure, we can support UDF, but does its partitions have to 
> be resizable/movable=3D3F I don't think it would be too bad if those 
> file 
> systems are not supported by the advanced partition manager 
> functions.

Yes, it seems we all agree on that. :-)

> Or we could introduce the requirement to unmount those partitions 
> first.

I wonder anyway, how it can be done, while the FS is mounted. I mean, 
even node IDs may change during resizing. I don't know the inner 
workings of the VFS, but at least applications holding a node=5Fref or an 
entry=5Fref (among them the Tracker, I suppose) may end up being very 
confused.

> > > > > > // large/small enough for initialization with a given 
> > > > > > system=3D3D3D3F
> > > > > > The
> > > > > > // parameter editor could alternately check for this.
> > > > > I would just add another method in BDiskSystem.
> > > > We could just add another file system error code for the
> > > > fs=3D3D3D5Finitialize() function.
> > > That's too late. In DriveSetup the GUI element for selecting the 
> > > system
> > > shall only show the feasible options. So, it must be known before
> > > fs=3D3D5Finitialze() is called.
> > Yes.
> 
> Okay, that makes sense :-)
> But then, there should be an explanation somewhere that those greyed 
> out file systems can't be installed on the partitions because they 
> are 
> likely to be too small.
> How about
> fs=3D5Fcheck=3D5Fpartition=3D5Flimits(off=3D5Ft offset, off=3D5Ft size);
> 
> in the FS API=3D3F Would that be enough=3D3F

All the BDiskSystem hooks should have counterparts in the FS API. There 
could also be one function that processes them all, like 
fs=5Fvalidate=5Foperation(uint32 operation, void *parameters).

> > > > > As said above, I would make them virtual. Moreover, the 
> > > > > Supports*
> > > > > System()
> > > > > should also have a BPartition* parameter. Otherwise 
> > > > > partitioning
> > > > > systems
> > > > > that allow only a limited number of levels can't give an
> > > > > authoritative
> > > > > answer here. The BPartition* parameter could optionally be 
> > > > > NULL 
> > > > > to
> > > > > ask
> > > > > whether it is supported in general.
> > > > I think there should be read-only set of classes, and an 
> > > > additional
> > > > add-on based set to actually do any changes. This will be only 
> > > > rarely
> > > > used, so it probably doesn't make much sense to clobber the 
> > > > general
> > > > API with it - so I like something BDiskSystem (as a virtual 
> > > > (and
> > > > abstract) base class), but it should contain everything, and 
> > > > not 
> > > > only the 
> > > > check operations.
> > > > Thoughts=3D3D3D3F
> > > You mean that e.g. BPartition::Move() would be ommitted in favor 
> > > of 
> > > a
> > > BDiskSystem::Move(BPartition*,...)=3D3D3F
> > > Mmh, that doesn't sound very convenient.
> > No, I don't think I like that either.
> 
> It might not be convenient, but it would reduce the memory overhead 
> of 
> applications using the API. Unless the add-ons are only loaded when 
> the 
> app uses one of the partition type dependent functions the first 
> time.

It shouldn't be too hard to implemented it like that.

> I wouldn't like if the system has to load all partition add-ons for 
> Tracker, even if they are not going to be used at all. And that 
> separation could be made stronger with an extra class that combines 
> all 
> calls that would cause the add-on to be loaded.

If we really limit the userland add-ons to provide only the GUI for the 
system-specific parameters -- for intel partitions that would be the 
partition type and the `active' flag -- then the add-on won't be needed 
before the parameters are actually going to be displayed/edited.

We could even dynamically load/unload the add-ons. This means the add-
on has to be reloaded with every request of a parameter editor, but, 
since those add-ons won't be that huge, this will be reasonably fast 
(not that quick for laptop users, when the HD is turned off at that 
moment, though).

CU, Ingo