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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.