FreeLists / openbeosstorage / [openbeosstorage] Re: Partitioning rethink

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-03-19 at 12:06:08 [-0800], Axel D=3DF6rfler wrote:
> > Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > And while I'm thinking of it, Axel, can we add your modified=3D20
> version
> > > of
> > > the iso9660 add-on to the cvs=3D3D3F Also, do you mind if I move 
> > > the
> >=3D20
> > Sure, but it will only work under R5 as of now :-)
> Why is that=3F

I've already mentioned it in another mail, but the OpenBeOS FS API 
won't be 100% compatible with Be's - we'll lose some fs add-ons because 
of this, but nothing really important (dunno how useful the HFS add-on 
is today, but for example NTFS is quite behind and won't work properly 
with recent Windows versions anymore).
That way, I can considerably extend and improve that API, in order to 
make attributes more powerful and better integrated, move the query 
language into the kernel (or even userland), initialization, etc.
It looks like we'll also get FS identification into it as well :)

> > And please don't be to harsh on me - it's really some kind of a=3D20
> hack=3D20
> > ;-))
> Hey, if it works, that's what matters for the time being. Thanks! :-)

It does work, but I have at least one CD that crashes (but it might 
have done this with the original as well, since that one only contains 
an additional audio track - I have to investigate in this; the 
iso9660=5Fshell also crashes with this CD, so that shouldn't be sooo 
hard).

> > 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/.=3D20
> Well, if there's no good reason not to have it in os/drivers, I guess
> =3D20
> I'd vote for that.

Well, then let's have it there.

> > The cpp.cpp should probably be part of the src/
> > kernel/core directory, right=3F
> Sounds good to me. If they don't mysteriously move to those locations
> =3D20
> by the time I get around to checking in my first round of udf stuff,=3D
> 20
> I'll go ahead make the move, okay=3F=3D20=3D20

That would be perfectly okay, just make sure nothing breaks ;-)

> > We shouldn't force anyone to switch to C++ to use a kernel service
> > right now.
> Why not=3F (I'm just curious, not challenging; I do enjoy making cranky
> =3D20
> C programmers stretch their horizons ;-)

I don't want to shy away all those kernel geeks - many people actually 
believe that C++ doesn't belong into the kernel; they deny that C++ 
features are perfectly suited for the kernel - I don't understand 
what's so bad about better type safety and automatic deconstructions of 
stack objects, IMO they ease kernel development considerably, and 
improve code reliability and readability, but who cares ;)

Adios...
   Axel.