[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 29 Jun 2004 22:30:19 +0200 CEST
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:
