Re: Partitioning rethink

> > Ooops, my bad. I don't actually want to remove full userland
> > functionality, but I didn't really make that clear. I guess what I 
> > was
> > really getting at was this: what about adding an API to enumerate 
> > all
> > current mountable volumes? That seems like a useful service to 
> > provide,
> > and it has to be implemented for OpenTracker anyway, right? This 
> > way it
> > could be used elsewhere.
> 
> Actually the DiskDevice API provides a means to enumerate all 
> mountable
> partitions: BDiskDeviceRoster::VisitEachMountablePartition(). Or is 
> there
> something you don't like this method for?

Arg. No, there's nothing wrong with it. In fact, I really like those 
visitor functions. I just somehow managed to completely forget about 
that one...

> [...]
> > Well, I did some more reading, and even read through the linux udf
> > filesystem mailing list archives, and here's what I've come up with:
> [...]
> 
> Sorry, I haven't yet found the time to read through the specs you 
> send us.
> :-(
> When I will have done it, I'll re-read the mail and complain noisily, 
> if
> there is something I disagree on -- not that I'm expecting that. ;-)

No worries. If you get a chance to read through them, great, if not, 
that's okay too. 

> > So, since single filesets spanning multiple volumes is part of the
> > post-R1 plans, I will not plan on supporting that feature in udf 
> > until
> > then (incidentally, I will be starting on a udf filesystem add-on as
> > soon as justifiably possible :-).
> 
> Cool! I can tell you, writing FSs is fun. 

I'm glad to hear that; I'm certainly looking forward to it. What ever 
happened to your Reiser add-on? 

And while I'm thinking of it, Axel, can we add your modified version of 
the iso9660 add-on to the cvs? Also, do you mind if I move the 
cpp.{h,cpp} files from BFS to somewhere more public so the rest of the 
kernel can share them?

> And have Axel send you his
> improved FS shell, in case he doesn't manage to check it in before. 
> :-P

Yes Axel, please do. :-)

> > I still would prefer we switch to a more generalized partitioning
> > scheme vs. the current session/partition/filesystem; sorry for 
> > pushing
> > for this so late in the process, but it's taken me this long to 
> > figure
> > out I really don't like the way we're doing things right now.
> 
> No worries, I always suspected something evil to happen, since 
> everything
> worked out just too well. ;-)

Ha. :-)

> > So, I guess my next task is to try to catch up with the current 
> > state
> > of the whole disk_scanner/DiskDevice API so I can help get things
> > finished up.
> 
> As far as I remember, there's not too much left to be done in the API
> implementation. Basically the support for partitioning and FS
> initialization. With the former one I've already started, and it 
> shouldn't
> take me that long to finish it, once my laptop problem is solved.
> 
> It would be great, if you could work on ideas, how the DiskDevice API
> should be changed (or rewritten) to reflect a generalized partitioning
> scheme. You know, like proposing new headers and such.

In progress now.

> If that is done, we can think about how to move the DiskDevice API 
> related
> functionality from the registrar into the kernel and how we want to 
> adjust
> the disk_scanner API and the interface for the modules. That would be 
> my
> vision for the further proceeding. Does that sound reasonable?

Sounds good to me.

[scanner modules]
> > > Yes, a flag would do. Though in case of a CD, that wouldn't be
> > > necessary,
> > > since the module would know itself, that the thing to be examined 
> > > is
> > > not
> > > at top level, and thus could just reject it without doing 
> > > anything at
> > > all.
> >
> > How so (wrt knowing that the thing to be examined is not at the top
> > level)?
> 
> Er, well, that has to do with my idea to change the disk_scanner 
> module
> interface I have not yet made publicly known. ;-) In fact it's merely 
> the
> skeleton of an idea, and that's why I haven't mentioned it yet.
> 
> When we were discussing the ISO9660 volume groups it occured to me,
> that the modules simply get too few information. In that particular 
> case
> the iso9960 FS module -- it had to know former sessions/volumes, but 
> would
> not, unless rescanning the whole disk again.
> 
> And since the thought to move the registrar functionality into the 
> kernel
> came up, it seemed like a clever solution to supply the module with a
> RPartition (the registrar equivalent of a BPartition) object. It could
> simply get the parent objects (RSession, RDiskDevice) and traverse the
> tree in its current state at will, inspecting former
> RSessions/RPartitions of interest.
> 
> Similarly the other modules would get respective objects. With the
> suggestion to unify the notions of sessions and partitions, still the
> parent object could be supplied, which would be either a RDiskDevice 
> or a
> RPartition (i.e. two hook functions), or a common base class of which 
> one
> could get the type info, if needed.
> 
> As said before, this is just a rough idea, not worked out in detail. 
> Axel
> may for instance object, that C++ in the module interface is not 
> exactly
> something he likes -- which could be worked around by using ugly ;-) C
> structures instead -- or something else I don't think of, and perhaps
> wouldn't have an answer to...

Yeah, I like that idea. And C++ (or something very similar) works for 
me. :-)

-Tyler