Re: Amiga RDB
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <Pine.SOL.4.53.0306111408530.20404@basta> |
On Wed, 11 Jun 2003, Axel Dörfler wrote: > Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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