Re: Getting rid of kernel_interface.POSIX.cpp

On 2004-06-28 at 23:53:05 [+0200], Axel D=F6rfler wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > On 2004-06-26 at 20:48:53 [+0200], Tyler Dauwalder wrote:
> > > On 2004-06-26 at 07:36:04 [-0700], Axel D=F6rfler wrote:
> > > > While kernel_interface.POSIX.cpp (and the general approach behind
> > > > it)
> > > > is very useful for porting, is it planned to get rid of that
> > > > extra
> > > > level of indirection one day?
> > > It's planned to replace it with routines that access the kernel
> > > functionality directly, i.e. to add a kernel_interface.x86.cpp.
> > While I originally found that a good idea, too, I'm not longer
> > convinced
> > that it is. Some parts are bloated: We have for instance four open()
> > functions while R5's libroot has only one _kopen_() syscall. And that
> > one is
> > even more powerful as it allows to specify the entry in question per
> > FD +
> > relative path combination. Some other syscalls have that feature too,
> > obviously being perfectly suited for BEntrys or BDirectory + relative
> > path
> > combinations. By using our interface we make the API classes
> > implementations
> > not only more complicated but also less performant.
>=20
> 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=
=20
complicated. The unit test framework uses quite a bit of BeOS API itself=20
(and the STL!), so it might be not so easy to get the tests run under Hai=
ku=20
in the first place.

> 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 t=
he=20
transition. By then my job should go considerably easier, leaving me a=20
reasonable amount of spare time again.

> 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 mea=
ns=20
of the public C API. There should only be a handful of additional syscall=
s=20
be needed. Like a _kern_open(), _kern_read_stat(), _kern_write_stat() wit=
h=20
FD + relative path parameters, syscalls to read and write symlinks per FD=
,=20
as well as syscalls for node locking and node monitoring.

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

> [libstdc++]
> > > > It would have been great if someone had thought about
> > > > this particular dependency earlier...
> > > I believe the attitude was that we had no choice but to include a
> > > libstdc++
> > > in Haiku, since R5 had one publicly usable as well, so we might as
> > > well
> > > take advantage of it if doing so would make our lives easier. I'm
> > > unaware
> > > of what the difficulties of getting our own libstdc++ working are
> > > exactly;
> > > do you have a good feel for that?
> > I also don't see why using the STL should be a problem. Erik,
> > apparently
> > being an STL fan, used it for some App Kit implementations as well.
> > So we
> > have to have an STL implementation before being able to port libbe to
> > our
> > kernel, but with a more or less complete C library it shouldn't be
> > difficult
> > to port a free STL implementation, or should it?
>=20
> 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=20
questions of STL binary compatibility almost two years ago, and for some=20
reasons it didn't led to a serious discussion. The best solution, I have=20
heard since that time though, is to work around the matter of STL binary=20
compatibility by simply including R5's libstdc++.r4.so and use a current=20
STLport, probably dropping source compatibility -- but who cares.

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

CU, Ingo