Re: API Extensions

> 
> > > [...]
> > > > > 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.

> 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?

CU, Ingo