Re: Getting rid of kernel_interface.POSIX.cpp

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?
>=20
> 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=20
that it is. Some parts are bloated: We have for instance four open()=20
functions while R5's libroot has only one _kopen_() syscall. And that one=
 is=20
even more powerful as it allows to specify the entry in question per FD +=
=20
relative path combination. Some other syscalls have that feature too,=20
obviously being perfectly suited for BEntrys or BDirectory + relative pat=
h=20
combinations. By using our interface we make the API classes implementati=
ons=20
not only more complicated but also less performant.

Moreover we have a couple of functions, I don't understand why we introdu=
ced=20
them in the first place. Like stat_dev(), the attribute and the query=20
functions. Most of them simply wrap the libroot call and are used in exac=
tly=20
one place in the implementation of the libbe API classes.

And finally there are parts missing in our interface, where only private=20
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=
=20
some point in the future, thoroughly revising the API classes=20
implementations. Maybe not right now, because it may help to port the=20
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).
>=20
> The MIME database stuff uses it as well.
>
> > It would have been great if someone had thought about
> > this particular dependency earlier...
>=20
> I believe the attitude was that we had no choice but to include a libst=
dc++
> 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 unawa=
re
> of what the difficulties of getting our own libstdc++ working are exact=
ly;
> do you have a good feel for that?

I also don't see why using the STL should be a problem. Erik, apparently=20
being an STL fan, used it for some App Kit implementations as well. So we=
=20
have to have an STL implementation before being able to port libbe to our=
=20
kernel, but with a more or less complete C library it shouldn't be diffic=
ult=20
to port a free STL implementation, or should it?

> > Speaking of the Sniffer - what does it do there? I thought it was par=
t
> > of the Registrar and only used by the storage kit? Or is it common to
> > both?
>=20
> They both use it. Basically all the actual MIME database related code l=
ives
> 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 th=
e
> Storage Kit).

That reminds me that I never got to ask, why you moved the=20
{CreateAppMetaMime,MimeUpdate,UpdateMimeInfo}Thread stuff from the regist=
rar=20
into libbe. They aren't used in Storage Kit, are they?

CU, Ingo