Re: Getting rid of kernel_interface.POSIX.cpp

Tyler Dauwalder <tyler-cyCl/[email protected]> Tue, 29 Jun 2004 08:59:17 -0700
Newsgroups gmane.os.openbeos.storage
Message-ID <20040629085917.478.1@heroin_bob.attbi.com>
> > 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 direct=
ly
> > 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 nee=
d
> > to perform the tests for our kit under R5 when we can do the same und=
er
> > 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.
>=20
> I would in principle vote for a), but things are unfortunately a bit mo=
re
> complicated. The unit test framework uses quite a bit of BeOS API itsel=
f
> (and the STL!), so it might be not so easy to get the tests run under H=
aiku
> in the first place.

We're not really in any terrible hurry to get the tests working again=20
anyway. It would be nice to have them, but I don't think it's critical fo=
r=20
the time being. We'll have enough support for them to build and run under=
=20
Haiku eventually, and we can deal with any issues they uncover at that ti=
me.=20
So I'd say a) is fine with me too.

On 2004-06-28 at 14:53:05 [-0700], 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:
> > > > 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?
>=20
> Yeah, Tyler, why did you do that? ;-))

You ought to have asked that when I did it, because I have absolutely no=20
recollection of the reasoning behind that anymore. :-) If I ever figure i=
t=20
out, I'll let you know. :-)

-Tyler