Re: Getting rid of kernel_interface.POSIX.cpp

On 2004-06-29 at 22:30:19 [+0200], Axel D=F6rfler wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > On 2004-06-28 at 23:53:05 [+0200], Axel D=F6rfler 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.
>=20
> 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=20
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 i=
s=20
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.
>=20
> 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.
>=20
> 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, ...)?
>=20
> But anyway, we can think about that later.

Yep, it might be handy. When revising the classes implementation it will=20
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
>=20
> 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.
>=20
> 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.
>=20
> 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=20
libstdc++.r4.so we steal from R5 would just be there for binary=20
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.
>=20
> 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 real=
ly=20
true, as it contains libgcc) I would find it strange to include the STL=20
stuff there. But hey, you started about integrating it into libroot -- I=20
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 purs=
ue=20
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=20
need to feed the link rule with the names of the object files, which you=20
don't have at that time. At least not in a generic way. I guess one has t=
o=20
list the object files explicitly. This would read like:

LIBGCC_OBJECTS =3D foo.o bar.o ... ;
LIBGCC_OBJECTS =3D $(LIBGCC_OBJECTS:G=3Dlibgcc) ;
UnarchiveObjects $(LIBGCC_OBJECTS) : $(LIBGCC) ;
...
Link libroot.so : ... $(LIBGCC_OBJECTS) ... ;

The UnarchiveObjects rule should be straight forward, i.e. adding the=20
dependencies, setting SEARCH and LOCATE...

CU, Ingo