
|
[openbeosstorage]
||
[Date Prev]
[06-2003 Date Index]
[Date Next]
||
[Thread Prev]
[06-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: Amiga RDB
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 11 Jun 2003 15:38:17 +0200 (MEST)
On Wed, 11 Jun 2003, Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On Wed, 11 Jun 2003, Axel Dörfler wrote:
> [driver_settings enhancements]
> > > Hm... I could try to do that tomorrow, but if I don't find the
> > > time,
> > > feel free to do it.
> > I guess, I'll reach the point, where I need it (well, `need' is not
> > exactly correct, since it would be possible to leave the parameter
> > stuff
> > out for scanning, but it would be nice to have it, for that part
> > could be
> > completed then) Friday or on the weekend at the latest. So, if you
> > haven't
> > done it till then, I'll just go ahead and implement it.
>
> Fair enough - but I'll try to be faster than you this one time :-)
I wouldn't be too disappointed. ;-)
> > > But it should probably be moved from kernel/core to kernel/libroot/
> > > os/
> > > right?
> > It will be needed in both kernel- and userland, and unless I'm
> > mistaken,
> > the kernel is not supposed to access libroot, is it? So, it has to be
> > compiled and linked into both, and, I think, it doesn't make much
> > difference where the sources are located, then.
>
> For the build yes, but for the cleanliness of the tree, I would rather
> have it in libroot. The kernel doesn't link against the whole libroot,
> but statically against parts of it.
> I wanted place every Posix like calls under libroot/posix usable by
> both, and the OS specific stuff in libroot/os - also usable by both
> parties.
> In fact, many files are already used in this way.
OK, then it makes sense to do it the same way.
> > > Maybe we want to wait with that move until we have our own
> > > repository,
> > > though, to not lose any changes information.
> > Have I missed something? Have the plans to move to an own server
> > become
> > more concrete? I thought, it was agreed on leaving the repository at
> > SF
> > for the time being, perhaps do mirror it at our site, and decide
> > later on
> > whether or not to move it.
>
> I thought we would do that some day. But maybe it's still far away in
> the future.
We'll see.
> > However, as SF provides a CVS tarball, we wouldn't lose any version
> > info,
> > if we would move, anyway.
>
> True - even if it's in the attic it's still there :-)
Exactly.
> Maybe I will just move it then before doing any changes. We might want
> to recompile it with different capabilities though at a later time.
Different capabilities?
CU, Ingo
|

|