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