> > 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