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

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2004-06-28 at 23:53:05 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2004-06-26 at 20:48:53 [+0200], Tyler Dauwalder wrote:
> > > On 2004-06-26 at 07:36:04 [-0700], Axel Dörfler 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.
> 
> 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.

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

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

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

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

> 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