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

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2004-06-29 at 22:30:19 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2004-06-28 at 23:53:05 [+0200], Axel Dörfler wrote:
> > > Yes, I am all for removing the separated kernel_interface, too.
> > > However, how should the transition be done?
> > > Right now, there are already some places where the Storage Kit
> > > directly
> > > calls R5's syscalls - of course, those would have to be changed
> > > first,
> > > as they don't build under Haiku, and I don't intend to add these
> > > syscalls :)
> > > My suggestions are these, either:
> > > a) ditch R5 compatibility; we have our tests written, there is no
> > > need
> > > to perform the tests for our kit under R5 when we can do the same
> > > under
> > > Haiku.
> > > b) conditionally compilable for R5; i.e. if some macro like
> > > COMPILE_FOR_R5 is defined, _kstart_watching_ is used instead of
> > > _kern_start_watching.
> > I would in principle vote for a), but things are unfortunately a bit
> > more
> > complicated. The unit test framework uses quite a bit of BeOS API
> > itself
> > (and the STL!), so it might be not so easy to get the tests run under
> > Haiku
> > in the first place.
> 
> 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. :-)

> 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.

> > > In any case, I am willing to help with the transition on both sides
> > > - I
> > > probably have to do provide the kernel API for you anyway, and I
> > > know
> > > Ingo doesn't have that much time before his Bruce-in-China trip :)
> > 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.

> I wish you a great experience! :)

Thanks a lot. :-)

> > > But since you know a lot more about the Storage Kit's needs, it
> > > would
> > > be nice to share some insight, i.e. what type of calls you would
> > > like
> > > to have, and why.
> > I can't list them off the top of my head. Most can already be done by
> > means
> > of the public C API. There should only be a handful of additional
> > syscalls
> > be needed. Like a _kern_open(), _kern_read_stat(), _kern_write_stat()
> > with
> > FD + relative path parameters, syscalls to read and write symlinks
> > per FD,
> > as well as syscalls for node locking and node monitoring.
> 
> 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.

> > > [...]
> > > > To sum it up, I would vote for completely getting rid of the
> > > > interface at
> > > > some point in the future, thoroughly revising the API classes
> > > > implementations. Maybe not right now, because it may help to port
> > > > the
> > > > Storage Kit faster to our kernel, but definitely before R1 is
> > > > shipped.
> > > I think so, too. I would start with the non-POSIX calls like the
> > > syscalls and the stuff in LibBeAdapter, and then one after another,
> > > remove all other parts of the private API.
> > I'd probably go the do-it-all-in-one-big-sweep way, but whatever
> > works is
> > fine. BTW, I would actually not have started with porting our libbe
> > until
> 
> I'd be glad if we could do it in one sweep - I just wouldn't do it
> myself (alone) this way, as it has a lower priority for me :-)

Yep, that's understandable.

> > the app server was in state that would allow large parts of libbe to
> > work.
> > Not necessarily the Interface Kit as a whole but at least BBitmap,
> > which is
> > required by the Storage Kit. We once had a quite usable state, when
> > the
> > registrar work was basically done. At that time I had provided a
> > quick and
> > dirty BBitmap implementation that didn't require an app server
> > connection.
> > Maybe it would be a good idea to isolate the app server depending
> > code via
> > #ifdefs to try and get a reasonable large coherently and
> > independently
> > working portion of libbe (the Support, Storage and main parts of the
> > App
> > Kit, together with the registrar of course) and port that as a
> > beginning.
> 
> 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? :-)

> I just have to squash out some serios bugs before...

Yep, do that. :-)

> > > [libstdc++]
> > > It's a problem for exactly one reason: we don't have a libstdc++ at
> > > this point. There is no team that works on this or anyone doing any
> > > work, there is no source of the version Be used.
> > > If we don't achieve binary compatibility with it (that's why we
> > > can't
> > > use STLport for example - which was already ported over by Marin
> > > alias
> > > Ahwayakchih alias Shard), we would have to provide two different C+
> > > +
> > > libraries, which I really wouldn't like.
> > > We would need to get a current C++ library and try to make it
> > > binary
> > > compatible - that sounds like a lot of fun...
> > >
> > > But since that all is still unresolved, I think it's the wrong
> > > signal
> > > to use it everywhere :)
> > Risking to sound like a know-it-all, I already tried to bring up the
> > questions of STL binary compatibility almost two years ago, and for
> > some
> > reasons it didn't led to a serious discussion. The best solution, I
> > have
> > heard since that time though, is to work around the matter of STL
> > binary
> > compatibility by simply including R5's libstdc++.r4.so and use a
> > current
> > STLport, probably dropping source compatibility -- but who cares.
> 
> Well, in that case, I would try to remove the dependency for libbe.so
> on libstdc++ - because I wouldn't like if we need to have two of those
> libraries around by design always.

Why would we have two libstdc++ libs around by design? As I see it, the 
libstdc++.r4.so we steal from R5 would just be there for binary 
compatiblity. The system libraries and applications wouldn't use it.

> But as you do, I am not worried about source compatibility - a header
> change here and there is fine, especially when it improves things :-)

Definitely.

> > > Since when it's loaded anyway all the time for all applications, we
> > > could integrate it into libroot as well.
> > If at all then into libbe. But I don't see reasons for that either.
> 
> Why libbe.so? Then all apps that need C++ functionality would need to
> link against libbe.so. Okay, that should be harmless, but it would be
> kinda strange if a C++ app would need to link against libbe.so just for
> some C++ features.

As libroot is (currently) a C only library (well that's actually not really 
true, as it contains libgcc) I would find it strange to include the STL 
stuff there. But hey, you started about integrating it into libroot -- I 
would preferably leave it as a separate lib.

> Anyway, adding it to libroot.so would probably make loading a bit
> faster - but there are a lot of other methods to work on that, too. And
> right now, we don't even know how much of a problem it will get.

Before starting to glue libraries it's probably a reasonable idea to pursue 
other potential path for optimizations first.

> 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...

CU, Ingo