[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On 2004-06-29 at 22:30:19 [+0200], Axel Dörfler wrote:
> > I don't completely understand; for a start, we can simply copying 
> > over
> > libstdc++.r4.so.
> Yes, we can copy it. The question is actually whether it works with 
> our 
> libroot. :-)

As Oliver found out, the libstdc++.r4 code is available at GeekGadgets, 
too, so it looks like we've almost solved the issue (he is currently 
trying to get it to run with our libio version...)

> > Also, we do have all the Be API in place, don't we?
> > Only functions that require an app_server connection won't work. 
> > Which
> > is perfectly okay for now, I'd think, as we know which APIs are
> > affected and why.
> Currently the unit testing stuff uses BApplication. It may be that 
> this is 
> only for the BTestApp class though.

Can we solve this? Regression testing is not that senseless :)
OTOH there is no pressure, we could run the tests later, too (and fix 
any issues then).

> > > I'd actually love, if you could wait a month, so that I could 
> > > help
> > > with the transition. By then my job should go considerably 
> > > easier, 
> > > leaving me a reasonable amount of spare time again.
> > Sure, I can do that. I will just replace the BeOS syscalls with 
> > Haiku
> > syscalls to make it link (and work) on our system (node watching).
> OK, cool.

There you go :)
I've changed libbeadapter.so to provide the new Haiku syscalls, and 
changed all direct syscall uses to the new ones. The build system now 
builds libbe.so as a stand-alone (and actually working) object.

> > What about special entry_ref support? Should there be functions 
> > that
> > directly take an entry_ref, too?
> > I.e. something like:
> > _kern_open(int fd, entry_ref *ref, const char *path, ...)?
> > or
> > _kern_open(int fd, dev_t device, ino_t parent, const char *path, 
> > ...)?
> > 
> > But anyway, we can think about that later.
> Yep, it might be handy. When revising the classes implementation it 
> will 
> become much clearer, what actuallly makes sense. So let's way until 
> then.

Okay.

> > Dunno; I think we can live without app_server for now. When the 
> > issue
> > becomes more pressing, and the app_server team doesn't deliver, we
> > could ask them to make us a version that doesn't do graphics - I 
> > would
> > think that this can't be that hard.
> > We may also be able to run parts of the Media Kit then :-)
> Yeah, the whole thing starts to really get exciting, doesn't it? :-)

Definitely!

> > I just have to squash out some serios bugs before...
> Yep, do that. :-)

Still need to :)

> > BTW libgcc.a is linked into libroot.so; and I need it to export all
> > functions that others could need. Marcus had the great idea to
> > dearchive libgcc.a and link the object files together into 
> > libroot.so.
> > Do you have a quick idea on how a Jamrule achieving this could look
> > alike?
> I'm afraid there is no nice solution using jam. The problem is, that 
> you 
> need to feed the link rule with the names of the object files, which 
> you 
> don't have at that time. At least not in a generic way. I guess one 
> has to 
> list the object files explicitly. This would read like:
> 
> LIBGCC_OBJECTS = foo.o bar.o ... ;
> LIBGCC_OBJECTS = $(LIBGCC_OBJECTS:G=libgcc) ;
> UnarchiveObjects $(LIBGCC_OBJECTS) : $(LIBGCC) ;
> ...
> Link libroot.so : ... $(LIBGCC_OBJECTS) ... ;
> 
> The UnarchiveObjects rule should be straight forward, i.e. adding the 
> dependencies, setting SEARCH and LOCATE...

I've done it this way, now - have a look if you like it :-)

Bye,
   Axel.

Other related posts: