Re: Amiga RDB
"Axel Dörfler" <[email protected]>
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <1519789514-BeMail@nichtsnutz> |
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote: > > Correct me if I'm not following along here, but say you have a disk > > with an Amiga RDB that has a single Amiga FFS partition. Wouldn't > > the > > BDiskDevice partition get the RBD's block size, and the single > > child > > BPartition get the disk_environment size? > I can only second that question. There seems to be no problem in my > eyes. Yes, there doesn't seem to be one. > > > > I'm not even sure, that I want to enforce to use the driver > > > > settings > > > > format for the parameters. Most modules will certainly want to > > > > use > > > > it, > > > > since it saves them the parsing/unparsing task, but I wouldn't > > > > rule > > > > out, that there might be a disk system, which has it's > > > > parameters > > > > already in a handy string form (in case it's just a name or > > > > something like this) and would unnecessarily need to convert > > > > it. > > But if it's something simple like that, converting it into > > driver_settings format won't be too taxing either. > OK, you have a point here. :-) Fine :-)) > > > For file systems, I want to enforce the driver_settings format. I > > > don't > > > know if it makes sense to loosen that limit for the partition > > > modules, > > > but if you could come up with a good reason :-) > > > And that information would only be of interest for file systems, > > > so we > > > could just add it there. But we'll see - I still have to extend > > > the > > > current driver_settings implementation for this usage. > Since I will need it rather soon -- basically only the disk system > management in KDiskDeviceManager and the basic C functions exported > by the > disk manager are to be done, before I will start to port the intel > module > to the new interface -- I can do that, if you don't object. Hm... I could try to do that tomorrow, but if I don't find the time, feel free to do it. But it should probably be moved from kernel/core to kernel/libroot/os/ right? Maybe we want to wait with that move until we have our own repository, though, to not lose any changes information. OTOH there haven't been a lot. Also keep in mind that this file has to be used in the boot loader, too - though it would be okay to cut some of its functionality out. I also need to clean it up a bit, since the boot loader now has a Posix -like environment, the special open/read/write ops don't have to be used anymore. > > > a) give it a lower priority, so that it alsways comes last to > > > identify > > > a partition > > a) seems like it would be sufficient to me. > Yes, it seems to make some sense to give a system with laxer > constraints a > lower priority. Yes, I think so too. Adios... Axel.