[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On 2004-06-28 at 23:53:05 [+0200], Axel Dörfler wrote:
> > 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.
> I would in principle vote for a), but things are unfortunately a bit 
> more 
> complicated. The unit test framework uses quite a bit of BeOS API 
> itself 
> (and the STL!), so it might be not so easy to get the tests run under 
> Haiku 
> in the first place.

I don't completely understand; for a start, we can simply copying over 
libstdc++.r4.so.
Also, we do have all the Be API in place, don't we?
Only functions that require an app_server connection won't work. Which 
is perfectly okay for now, I'd think, as we know which APIs are 
affected and why.

> > 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 :)
> I'd actually love, if you could wait a month, so that I could help 
> with the 
> transition. By then my job should go considerably easier, leaving me 
> a 
> reasonable amount of spare time again.

Sure, I can do that. I will just replace the BeOS syscalls with Haiku 
syscalls to make it link (and work) on our system (node watching).
I wish you a great experience! :)

> > 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.
> I can't list them off the top of my head. Most can already be done by 
> means 
> of the public C API. There should only be a handful of additional 
> syscalls 
> be needed. Like a _kern_open(), _kern_read_stat(), _kern_write_stat() 
> with 
> FD + relative path parameters, syscalls to read and write symlinks 
> per FD, 
> as well as syscalls for node locking and node monitoring.

What about special entry_ref support? Should there be functions that 
directly take an entry_ref, too?
I.e. something like:
_kern_open(int fd, entry_ref *ref, const char *path, ...)?
or
_kern_open(int fd, dev_t device, ino_t parent, const char *path, ...)?

But anyway, we can think about that later.

> > [...]
> > > 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.
> I'd probably go the do-it-all-in-one-big-sweep way, but whatever 
> works is 
> fine. BTW, I would actually not have started with porting our libbe 
> until 

I'd be glad if we could do it in one sweep - I just wouldn't do it 
myself (alone) this way, as it has a lower priority for me :-)

> the app server was in state that would allow large parts of libbe to 
> work. 
> Not necessarily the Interface Kit as a whole but at least BBitmap, 
> which is 
> required by the Storage Kit. We once had a quite usable state, when 
> the 
> registrar work was basically done. At that time I had provided a 
> quick and 
> dirty BBitmap implementation that didn't require an app server 
> connection. 
> Maybe it would be a good idea to isolate the app server depending 
> code via 
> #ifdefs to try and get a reasonable large coherently and 
> independently 
> working portion of libbe (the Support, Storage and main parts of the 
> App 
> Kit, together with the registrar of course) and port that as a 
> beginning.

Dunno; I think we can live without app_server for now. When the issue 
becomes more pressing, and the app_server team doesn't deliver, we 
could ask them to make us a version that doesn't do graphics - I would 
think that this can't be that hard.
We may also be able to run parts of the Media Kit then :-)

I just have to squash out some serios bugs before...

> > [libstdc++]
> > 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 :)
> Risking to sound like a know-it-all, I already tried to bring up the 
> questions of STL binary compatibility almost two years ago, and for 
> some 
> reasons it didn't led to a serious discussion. The best solution, I 
> have 
> heard since that time though, is to work around the matter of STL 
> binary 
> compatibility by simply including R5's libstdc++.r4.so and use a 
> current 
> STLport, probably dropping source compatibility -- but who cares.

Well, in that case, I would try to remove the dependency for libbe.so 
on libstdc++ - because I wouldn't like if we need to have two of those 
libraries around by design always.

But as you do, I am not worried about source compatibility - a header 
change here and there is fine, especially when it improves things :-)

> > Since when it's loaded anyway all the time for all applications, we
> > could integrate it into libroot as well.
> If at all then into libbe. But I don't see reasons for that either.

Why libbe.so? Then all apps that need C++ functionality would need to 
link against libbe.so. Okay, that should be harmless, but it would be 
kinda strange if a C++ app would need to link against libbe.so just for 
some C++ features.
Anyway, adding it to libroot.so would probably make loading a bit 
faster - but there are a lot of other methods to work on that, too. And 
right now, we don't even know how much of a problem it will get.

BTW libgcc.a is linked into libroot.so; and I need it to export all 
functions that others could need. Marcus had the great idea to 
dearchive libgcc.a and link the object files together into libroot.so.
Do you have a quick idea on how a Jamrule achieving this could look 
alike?

Bye,
   Axel.

Other related posts: