[openbeosstorage] Re: API Extensions


On 2003-02-16 at 01:21:18 [-0800], Ingo Weinhold wrote:
> 
> > 
> > > > [...]
> > > > > > Yeah, might be right, but file systems could inspect the
> > > > > > intel
> > > > > > partition code field for their own use (even if the 
> > > > > > partition
> > > > > > add
> > > > > > -
> > > > > > on
> > > > > > couldn't find a nice string for it).
> > > > > Why should a FS be interested in that field=3F As it doesn't
> > > > > even
> > > > > exist
> > > > > for other partitioning systems, a FS can't (must not) rely on
> > > > > this
> > > > > value.
> > > > 
> > > > Right, it could use it as a extra validity check in combination
> > > > with
> > > > the partitioning type. Anyway, I don't remember right now if we
> > > > decided
> > > > to drop that field, I am fine with everything ;-))
> > > 
> > > I gave up. :-) It's still there but uint32 now.
> > 
> > I thought we were going to do something like "Unknown Type 0xFF" as
> > the
> > standard type string for unknown types,
> 
> That is done.

Great!

> 
> > and then drop the actual
> > partition code itself, thus leaving that information accessible, but
> > not in so nearly a convenient manner that it could be carelessly
> > abused.
> 
> Then there was a misunderstanding. The partition code is not available
> through the C++ API (unless the string is parsed), but I thought it
> should still be kept in the extend_partition_info structure. Axel's
> argument for that is, that a FS add-on should be able to check the
> partition type for validity, but, rethinking the matter now, I don't
> see why it shouldn't just check the string. I mean, it's not even more
> overhead, since it wouldn't need to parse the type string to get a
> code, but could just compare the string directly.
> 
> I tend to schedule the field for removal. Any other arguments against
> that?

Okay by me. Axel?

-Tyler

Other related posts: