[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 28 Jun 2004 23:53:05 +0200 CEST
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.
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 :)
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.
[...]
> 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.
[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 :)
Since when it's loaded anyway all the time for all applications, we
could integrate it into libroot as well.
> > > Speaking of the Sniffer - what does it do there? I thought it was
> > > part
> > > of the Registrar and only used by the storage kit? Or is it
> > > common to
> > > both?
> > They both use it. Basically all the actual MIME database related
> > code lives
> > in the Storage Kit. The registrar just provides the interface for
> > interacting with it (or most of it; some of it is handled locally
> > in the
> > Storage Kit).
> That reminds me that I never got to ask, why you moved the
> {CreateAppMetaMime,MimeUpdate,UpdateMimeInfo}Thread stuff from the
> registrar
> into libbe. They aren't used in Storage Kit, are they?
Yeah, Tyler, why did you do that? ;-))
Bye,
Axel.
Other related posts:
