FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> 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.