
|
[openbeosstorage]
||
[Date Prev]
[03-2003 Date Index]
[Date Next]
||
[Thread Prev]
[03-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: Partitioning rethink
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 19 Mar 2003 17:33:21 +0100 CET
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> And while I'm thinking of it, Axel, can we add your modified version
> of
> the iso9660 add-on to the cvs=3F Also, do you mind if I move the
Sure, but it will only work under R5 as of now :-)
And please don't be to harsh on me - it's really some kind of a hack ;-
))
> cpp.{h,cpp} files from BFS to somewhere more public so the rest of
> the
> kernel can share them=3F
Well, we can do it for now - if we'll find any problems with it at a
later date, we can simply remove them again.
The most public location for the header would be os/drivers/, a less
one private/kernel/. The cpp.cpp should probably be part of the src/
kernel/core directory, right=3F
> > And have Axel send you his
> > improved FS shell, in case he doesn't manage to check it in before.
> > :-P
> Yes Axel, please do. :-)
Yeah, I think I'll just do; it doesn't matter too much if it can't be
built from the start.
> > Similarly the other modules would get respective objects. With the
> > Axel may for instance object, that C++ in the module interface is
> > not
> > exactly something he likes -- which could be worked around by using
> > ugly ;-) C structures instead -- or something else I don't think
> > of, and
> > perhaps wouldn't have an answer to...
> Yeah, I like that idea. And C++ (or something very similar) works for
> me. :-)
I am not completely against introducing C++ API in the kernel itself -
but if we do, it *must* only be used for a specific case, and not be
usable by any other kernel components.
We shouldn't force anyone to switch to C++ to use a kernel service
right now.
Adios...
Axel.
|

|