[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 26 Jun 2004 22:54:03 +0200
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.
Moreover we have a couple of functions, I don't understand why we introduced
them in the first place. Like stat_dev(), the attribute and the query
functions. Most of them simply wrap the libroot call and are used in exactly
one place in the implementation of the libbe API classes.
And finally there are parts missing in our interface, where only private
syscalls exist in R5 (like for reading a symlink given a FD).
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.
> > Also, we don't yet have a libstdc++ - and yet, unlike the original
> > libbe.so, we have several components using it (IIRC only the sniffer in
> > the storage kit).
>
> The MIME database stuff uses it as well.
>
> > 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?
> > 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?
CU, Ingo
Other related posts:
