Partition Type ID (The RESULTs)
Stéphane Martineau
Here is the result of what everyone said in the
thread "New Partition Type ID (Please vote!)".
First, I want to say thank you to everyone that
participated. And if you didn't, you can continue
the conversation here.
If i've mistaken what you said or what your choice
was, just tell me and I will correct it.
Here's the results:
======================================
We've agreed on this:
1) The new partition type will be 0x7F and will be
called the "extended partition type" or EPT for short.
2) At least a basic reference to the extended partition
informations will be put into the first sector of the
partition. While the informations itself can be inside
the first sector or in other sectors if desired.
3) The partition type will be a string. Even proposals
for integer-id were used to store string-id :)
======================================
What we need to agreed on:
1) Where the informations will be and what it will be:
- I think it should be at a fixed location, no tag
should be used, there's no need for them and they use
bytes for no good reason. For now i'm voting for Jens
Olsson proposal of using a sector/offset (2 byte) but
without the tag which is NOT needed. I'm voting to put
those two bytes at offset 508-509 (0x1FC-0x1FD)
- Jens Olsson proposal add the tag "El", and i'm
guessing there's no fixed location ?
- Ayende Rahien essentialy seems to agree on
everything Jens as proposed.
- Aaron has many proposals, I guess I'm gonna let
him clarify is position :)
- The mysterious Mr. cr88192 :) seem to have opted
for a tag that can be in the first xK of the
partition. Anymore information about that ?
2) Should the string id be fixed of variable in
length.
- I prefer variable in length, null-terminated
and begin with a length-tag (a single byte).
- Ayende Rahien seem to agree with that.
- Aaron Grey want a variable string too.
- Jens Olsson seem to want a fixed string length of
16 bytes.
- A fixed string for cr88192 too (6 or 14 bytes)
3) Optional or mandatory fields/informations
beside the partition type.
- Myself, Aaron, Jens and Ayende seem to want
that.
- What about you cr88192 ?
- OK, now we need some proposal for the format
and the specification of that optional or/and
mandatory informations. I'm pretty open-minded
on that, so as long as there some flexibility
into it I'll agree to just about anything.
- Jens has already made a proposal, I've also
added a bit to that proposal and i'm waiting
for a specific Aaron proposal on this
subject.
======================================
I guess that's about everything! We can continue
the discussion in this thread ?
======================================
cr88192
> What we need to agreed on:
>
> 1) Where the informations will be and what it will be:
>
> - I think it should be at a fixed location, no tag
> should be used, there's no need for them and they use
> bytes for no good reason. For now i'm voting for Jens
> Olsson proposal of using a sector/offset (2 byte) but
> without the tag which is NOT needed. I'm voting to put
> those two bytes at offset 508-509 (0x1FC-0x1FD)
>
> - Jens Olsson proposal add the tag "El", and i'm
> guessing there's no fixed location ?
>
> - Ayende Rahien essentialy seems to agree on
> everything Jens as proposed.
>
> - Aaron has many proposals, I guess I'm gonna let
> him clarify is position :)
>
> - The mysterious Mr. cr88192 :) seem to have opted
> for a tag that can be in the first xK of the
> partition. Anymore information about that ?
>
the idea would be that a tag could be put in a number of places and could
be more or less independant of other structures. a problem with a tag is
that in some cases they can require more space and more checks are needed
to verify data integrity (and avoid false matches).
>
> 2) Should the string id be fixed of variable in
> length.
>
> - I prefer variable in length, null-terminated
> and begin with a length-tag (a single byte).
>
> - Ayende Rahien seem to agree with that.
>
> - Aaron Grey want a variable string too.
>
> - Jens Olsson seem to want a fixed string length of
> 16 bytes.
>
> - A fixed string for cr88192 too (6 or 14 bytes)
>
yep, in my mind this would just be placed at the end of the first sector.
for me variable strings will also work.
>
> 3) Optional or mandatory fields/informations
> beside the partition type.
>
> - Myself, Aaron, Jens and Ayende seem to want
> that.
>
> - What about you cr88192 ?
>
personally I had felt that the main goal was to generally identify the fs
type in a means reasonably independant of fs type. having other info would
be nice but personally I do not feel it is very essential...
> - OK, now we need some proposal for the format
> and the specification of that optional or/and
> mandatory informations. I'm pretty open-minded
> on that, so as long as there some flexibility
> into it I'll agree to just about anything.
>
> - Jens has already made a proposal, I've also
> added a bit to that proposal and i'm waiting
> for a specific Aaron proposal on this
> subject.
>
a chained string list might work.
consider: a way exists to locate the root string which likely identifies
the fs type. maybe each string could be prefixed by a reference to the next
string. maybe the value 0 or 0xffff could be used as a terminal marker.
each string could be either a pascal of c style string, maybe using '=' to
seperate the variable from the value.
it is possible that for pascal strings only values 0-127 could be used for
lengths, and 128-255 could indicate that the string is followed by a
reference to indicate the first child (a group).
this of course assumes that one wants a little more than just a fs type
though...
> ======================================
>
> I guess that's about everything! We can continue
> the discussion in this thread ?
>
> ======================================
yep...
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Francis Rounds
resist to chip in. I know I'm not exactly an a.o.d veteran, but what the
hell, I wanna be part of this standard! :)
Stéphane Martineau wrote:
> ======================================
>
> Here is the result of what everyone said in the
> thread "New Partition Type ID (Please vote!)".
>
> First, I want to say thank you to everyone that
> participated. And if you didn't, you can continue
> the conversation here.
>
> If i've mistaken what you said or what your choice
> was, just tell me and I will correct it.
>
> Here's the results:
>
> ======================================
> We've agreed on this:
>
> 1) The new partition type will be 0x7F and will be
> called the "extended partition type" or EPT for short.
>
> 2) At least a basic reference to the extended partition
> informations will be put into the first sector of the
> partition. While the informations itself can be inside
> the first sector or in other sectors if desired.
>
> 3) The partition type will be a string. Even proposals
> for integer-id were used to store string-id :)
>
I know it's already agreed, but I too agree with this.
>
> ======================================
> What we need to agreed on:
>
> 1) Where the informations will be and what it will be:
>
> - I think it should be at a fixed location, no tag
> should be used, there's no need for them and they use
> bytes for no good reason. For now i'm voting for Jens
> Olsson proposal of using a sector/offset (2 byte) but
> without the tag which is NOT needed. I'm voting to put
> those two bytes at offset 508-509 (0x1FC-0x1FD)
This proposal gets my vote. I too think that the "El" tag is unnecessary
and would waste a little space. Also, having the 2 bytes at 0x1FC-0x1FD
would make it easier for us, since one doesn't have to scan through the
whole sector (perhaps coming across several bogus pointer blocks on the
way).
>
> - Jens Olsson proposal add the tag "El", and i'm
> guessing there's no fixed location ?
>
> - Ayende Rahien essentialy seems to agree on
> everything Jens as proposed.
>
> - Aaron has many proposals, I guess I'm gonna let
> him clarify is position :)
*waits with baited breath for Aaron's further proposals* :)
>
> - The mysterious Mr. cr88192 :) seem to have opted
> for a tag that can be in the first xK of the
> partition. Anymore information about that ?
>
>
> 2) Should the string id be fixed of variable in
> length.
>
> - I prefer variable in length, null-terminated
> and begin with a length-tag (a single byte).
I think this is the best way to go. Has the potential to save space; of
course, in a worst case scenario, it could add two unnecessary bytes
onto the length of the string, but that's only if the string length is
>= 14. OK, so simplicity may be slightly reduced if this option gets
carried but, still, it's very flexible and so in my opinion, it's a good
idea.
>
> - Ayende Rahien seem to agree with that.
>
> - Aaron Grey want a variable string too.
>
> - Jens Olsson seem to want a fixed string length of
> 16 bytes.
>
> - A fixed string for cr88192 too (6 or 14 bytes)
>
>
> 3) Optional or mandatory fields/informations
> beside the partition type.
>
> - Myself, Aaron, Jens and Ayende seem to want
> that.
>
Yep, agreed there. I'm sure we'd all want that :)
> - What about you cr88192 ?
>
> - OK, now we need some proposal for the format
> and the specification of that optional or/and
> mandatory informations. I'm pretty open-minded
> on that, so as long as there some flexibility
> into it I'll agree to just about anything.
>
> - Jens has already made a proposal, I've also
> added a bit to that proposal and i'm waiting
> for a specific Aaron proposal on this
> subject.
IMO, Jens' proposal is very well thought out, and I will most likely
agree with a lot of it. Looks good so far!
>
> ======================================
>
> I guess that's about everything! We can continue
> the discussion in this thread ?
>
> ======================================
>
But of course :)
Now, lets hope this standard will be more of a C89 than a C99 :)
(BTW, is this going to be a complete democracy (every one gets their
vote) or are you going to form a sort of "standards commitee" for this?
If you're forming a commitee, I'd be interested in being in it :) To be
honest, I haven't contributed any new ideas, but I would like to help
shape the future of what hopefully will be a great a.o.d standard.)
Gonna be following developments on this very closely :)
Francis Rounds
Dark Fiber
<sma...@mail.com.NOSPAM> wrote:
>======================================
>
>Here is the result of what everyone said in the
>thread "New Partition Type ID (Please vote!)".
>
>
>======================================
>We've agreed on this:
>
>1) The new partition type will be 0x7F and will be
>called the "extended partition type" or EPT for short.
>
>2) At least a basic reference to the extended partition
>informations will be put into the first sector of the
>partition. While the informations itself can be inside
>the first sector or in other sectors if desired.
>
>3) The partition type will be a string. Even proposals
>for integer-id were used to store string-id :)
>
yuk ;) i'd rather have/parse an enumeration than a dictionary
>======================================
>What we need to agreed on:
>
>1) Where the informations will be and what it will be:
>
>- I think it should be at a fixed location, no tag
>should be used, there's no need for them and they use
>bytes for no good reason. For now i'm voting for Jens
>Olsson proposal of using a sector/offset (2 byte) but
>without the tag which is NOT needed. I'm voting to put
>those two bytes at offset 508-509 (0x1FC-0x1FD)
its not clear to me. is this 'two bytes' in the MBR sector or
some other sector? MBR is ugly enough as is, without extra
offset uglyness?
>- The mysterious Mr. cr88192 :) seem to have opted
>for a tag that can be in the first xK of the
>partition. Anymore information about that ?
>
i like this idea. scan first xKB for a header,
crc a block of code, if CRC matches, bingo.
(like scanning a grub header, or bios info, etc).
>2) Should the string id be fixed of variable in
>length.
>
>- I prefer variable in length, null-terminated
>and begin with a length-tag (a single byte).
cool. i could have a 256 byte identifier, using
unicode alphabet then? and waste half a sector
imo strings are too free-form.
>3) Optional or mandatory fields/informations
>beside the partition type.
>
>- OK, now we need some proposal for the format
>and the specification of that optional or/and
>mandatory informations. I'm pretty open-minded
>on that, so as long as there some flexibility
>into it I'll agree to just about anything.
>
dont agree to just about anything, be strict.
KISS.
dont add things that shouldnt be there,
things that will get used by 1 person and nobody
else, etc.
i dont want a 4kb structure full of crap to define a
partition entry.
off the top of my head
-partition type
-big/little endian (bit flag)
-start
-end
any extra info should be kept inside the partition, not described
by the partition entry.
-- Dark Fiber <yakum...@hotmail.com> --
[FAQ] Write Your Own Operating System
http://www.mega-tokyo.com/os
Roguelike News II
http://www.mega-tokyo.com/rlnews
Sarien Sierra AGI Emulator
http://www.mega-tokyo.com/sarien
3x3 Eyes Fanfiction Archive
http://www.mega-tokyo.com/pai
Stéphane Martineau
official here. It's just that some of us are planing to use or are already
using their own file system or partition architecture and since we all need
to choose an id for the partition type we just tought we could all use the
same one and add a bit of information into the partition itself to
differenciate them.
Hopefully it should be as democratic as possible and everybody that is still
here when the majority will agree, imo should be able to vote.
Stéphane Martineau
> be more or less independant of other structures. a problem with a tag is
> that in some cases they can require more space and more checks are needed
> to verify data integrity (and avoid false matches).
I also think it look like a hack, but that's probably just me :)
> yep, in my mind this would just be placed at the end of the first sector.
> for me variable strings will also work.
There should be no problem placing it at the end of the sector if you
want, even if it's variable in length.
> personally I had felt that the main goal was to generally identify the fs
> type in a means reasonably independant of fs type. having other info would
> be nice but personally I do not feel it is very essential...
I agree, the goal is to id the partition, the rest has to be optional.
> a chained string list might work.
> consider: a way exists to locate the root string which likely identifies
> the fs type. maybe each string could be prefixed by a reference to the
next
> string. maybe the value 0 or 0xffff could be used as a terminal marker.
> each string could be either a pascal of c style string, maybe using '=' to
> seperate the variable from the value.
> it is possible that for pascal strings only values 0-127 could be used for
> lengths, and 128-255 could indicate that the string is followed by a
> reference to indicate the first child (a group).
Yes, most proposal will be fine with me.
Aaron Gray
> (BTW, is this going to be a complete democracy (every one gets their
> vote) or are you going to form a sort of "standards commitee" for this?
> If you're forming a commitee, I'd be interested in being in it :) To be
> honest, I haven't contributed any new ideas, but I would like to help
> shape the future of what hopefully will be a great a.o.d standard.)
I think every one is included, thats why I termed it "the unoffical official
standard committee" :)
> Gonna be following developments on this very closely :)
Could be quite interesting, he he he.
Aaron
Stéphane Martineau
> > We've agreed on this:
>
That's great!
> This proposal gets my vote. I too think that the "El" tag is unnecessary
> and would waste a little space. Also, having the 2 bytes at 0x1FC-0x1FD
> would make it easier for us, since one doesn't have to scan through the
> whole sector (perhaps coming across several bogus pointer blocks on the
> way).
A checksum somewhere should be a requirement for a tag. But I still don't
want a tag either :)
> > 3) Optional or mandatory fields/informations
> > beside the partition type.
>
> Yep, agreed there. I'm sure we'd all want that :)
Maybe not everyone, but if it's optional it should be
acceptable to most, no ?
> Now, lets hope this standard will be more of a C89 than a C99 :)
Intel EFI is the way to go on the long term, but for everyone that need
to choose a partition type id right now, imo it should make that decision
very easy. The trouble might be to let them know about the existence of
the specification. I wasn't even aware of intel specification and they are
a giant compare to us :(
> (BTW, is this going to be a complete democracy (every one gets their
> vote)
I hope so. As far as I'm concern it will be with me!
Aaron Gray
still
> here when the majority will agree, imo should be able to vote.
There is a much larger community than is here at the moment, much larger,
there is the www.osdev.org group some of them may want to get involved.
Might be worth putting a message on the www.osdev.org mesage board at some
point.
I am thinking maybe we could do that putting a desired time limit for
proposals for a standard to be "in", not too strict.
Also I would like to gather a set "premises" for the design of the standard,
giving the general to the pragmatic, so that we come up with good designs
that are general enough to accommodate every ones need and to make sure that
the solution is future proof.
Aaron
Stéphane Martineau
> >for integer-id were used to store string-id :)
>
> yuk ;) i'd rather have/parse an enumeration than a dictionary
Well, you can see them both the same way, even more so if
the string-id is fixed in length. IMO the major problem with an
integer-id is that without a central authority to register them, it's
much more easier for two person to use the same id then with
a string-id.
> its not clear to me. is this 'two bytes' in the MBR sector or
> some other sector? MBR is ugly enough as is, without extra
> offset uglyness?
No, NOTHING will be in the MBR. The informations will be
in the partition itself.
> cool. i could have a 256 byte identifier, using
> unicode alphabet then? and waste half a sector
> imo strings are too free-form.
That's what make them flexible, and if you want to
waste half a sector or a billions it's your choice. But you
can also just use a few bytes 4-8 if you want.
You'd agree on a flexible tag, but not on a flexible
string-id ?
> dont agree to just about anything, be strict.
I am and I will. I just meant that I will wait a little bit for
all proposal before making some choice.
> dont add things that shouldnt be there,
> things that will get used by 1 person and nobody
> else, etc.
That is my point since the start. This is one of the
reason I don't agree with a tag, it's unecessary.
> i dont want a 4kb structure full of crap to define a
> partition entry.
I understand, this is why only the string-id will be
mandatory, the rest is optional. Many of us already intend
to have more informations then just the partition-id no
matter if it's part of the specification or just part of our own
partitions. So why not try to agree on the same basic
structure ? No one will be forced to use it if they don't
want/have more informations then the partition-id.
> any extra info should be kept inside the partition, not described
> by the partition entry.
Everything will be in the partition itself, not a single byte will be
added to the structure of the MBR. IMO that would be stupid.
Stéphane Martineau
> there is the www.osdev.org group some of them may want to get involved.
>
> Might be worth putting a message on the www.osdev.org mesage board at some
> point.
Yes, more peoples there is better it will be. We could also write email to
everyone
we can find that is writing an os (has a webpage), they could be very
interested
too.
> I am thinking maybe we could do that putting a desired time limit for
> proposals for a standard to be "in", not too strict.
I'm not sure if we need that for now. But i agree that we should have a
non-offical,
non too strict dead line at some point.
> Also I would like to gather a set "premises" for the design of the
standard,
> giving the general to the pragmatic, so that we come up with good designs
> that are general enough to accommodate every ones need and to make sure
that
> the solution is future proof.
You could collect them and pass them to Jens if you don't want to write the
doc
yourself. And as much as possible you should take into account what
everybody
said and on what we've agreed so far, even if nothing of that is offical.
Jens Olsson
>i like this idea. scan first xKB for a header,
>crc a block of code, if CRC matches, bingo.
>(like scanning a grub header, or bios info, etc).
>
>
I had that in my first proposal but everyone else except you and
cr88192 seem to be againt the idea. I thought we should have a tag
because it gives more freedom to place stuff here you want....
I have removed the tag from my proposal for now
//Jens
-----------
Remove _spamno_ from my e-mail address if you like to reply via e-mail
mailto:%6A%65%6E%73%40%7A%65%6B%72%61%2E%73%65
The OS Journal
--------------
www.osjournal.hopto.org - Main URL
www.osjournal.tk - Backup URL
www.cyberscriptorium.com/osjournal/cgi-bin/index.pl?action=home
My personal page
----------------
jenssoftware.hopto.org (NO WWW.!!!)
Aaron Gray
larger,
> > there is the www.osdev.org group some of them may want to get involved.
> >
> > Might be worth putting a message on the www.osdev.org mesage board at
some
> > point.
>
> Yes, more peoples there is better it will be. We could also write email to
> everyone we can find that is writing an os (has a webpage), they could
> be very interested too.
It would be nice to put together a e-mail list, the first e-mail could be
one asking whether people want to be on that list :)
A list manager may be a good idea.
> > I am thinking maybe we could do that putting a desired time limit for
> > proposals for a standard to be "in", not too strict.
>
> I'm not sure if we need that for now. But i agree that we should have a
> non-offical,
> non too strict dead line at some point.
What about one for preliminary standards say 2 weeks or a month ? Allowing
for alerting other non or non regulatr alt.os.dev'ers.
> > Also I would like to gather a set "premises" for the design of the
> standard,
> > giving the general to the pragmatic, so that we come up with good
designs
> > that are general enough to accommodate every ones need and to make sure
> that
> > the solution is future proof.
>
> You could collect them and pass them to Jens if you don't want to write
the
> doc
> yourself. And as much as possible you should take into account what
> everybody
> said and on what we've agreed so far, even if nothing of that is offical.
I should be able to do the documentation, although, PDFing it would be nice,
although I will probably use a web page.
I do not know whether Jens would be interested or not ?
The idea with the premises is to get together a set of "thruths" or "ideals"
for the design. They are intended to help design, and to allow design
descisions to be checked.
I still have to look some more areas before being sure enough about them. I
will put them up as a heading mail soon, Hopefully others may contribute.
Aaron
Aaron Gray
> >crc a block of code, if CRC matches, bingo.
> >(like scanning a grub header, or bios info, etc).
> >
> >
>
> I had that in my first proposal but everyone else except you and
> cr88192 seem to be againt the idea. I thought we should have a tag
> because it gives more freedom to place stuff here you want....
> I have removed the tag from my proposal for now
I am in agreement with a tag or signature in principle, it is just the space
issue and that I do not like you El, is that a little L or what ? What does
it mean and where did it come from ?
Are you interested in my "Premises" idea ? See my voting on Stephane's
voting thread.
Aaron
Stéphane Martineau
> one asking whether people want to be on that list :)
> A list manager may be a good idea.
Yes, anyone interested ?
> What about one for preliminary standards say 2 weeks or a month ? Allowing
> for alerting other non or non regulatr alt.os.dev'ers.
The end of the month sound good, but there's no rush.
> The idea with the premises is to get together a set of "thruths" or
"ideals"
> for the design. They are intended to help design, and to allow design
> descisions to be checked.
The problem might be that we will first have to agree upon that set of
premises before agreeing on anything else. IMO it might just make
things more complicated. It's simplier to start with what we already have
from everybody's posts (if you're missing some you can get them on
goggles) and continue from that. There's many good points in what
everybody said and we should take all that into account. If we found
out that many peoples disagreed then we'll change it to go with the
majority.
IMO, this should be more practical then academic.
Aaron Gray
> premises before agreeing on anything else. IMO it might just make
> things more complicated. It's simplier to start with what we already have
> from everybody's posts (if you're missing some you can get them on
> goggles) and continue from that. There's many good points in what
> everybody said and we should take all that into account. If we found
> out that many peoples disagreed then we'll change it to go with the
> majority.
That is where I was and am drawing the "universals" from :)
> IMO, this should be more practical then academic.
I like to be in both camps at the same time.
Aaron
Dark Fiber
<sma...@mail.com.NOSPAM> wrote:
>> cool. i could have a 256 byte identifier, using
>> unicode alphabet then? and waste half a sector
>> imo strings are too free-form.
>
>That's what make them flexible, and if you want to
>waste half a sector or a billions it's your choice. But you
>can also just use a few bytes 4-8 if you want.
>
>You'd agree on a flexible tag, but not on a flexible
>string-id ?
>
i was being sarcastic.
>> any extra info should be kept inside the partition, not described
>> by the partition entry.
>
>Everything will be in the partition itself, not a single byte will be
>added to the structure of the MBR. IMO that would be stupid.
>
aaah. ok. i thought the idea was to replace what is stored in the MBR.
Jens Olsson
>Intel EFI is the way to go on the long term, but for everyone that need
>to choose a partition type id right now, imo it should make that decision
>very easy. The trouble might be to let them know about the existence of
>the specification. I wasn't even aware of intel specification and they are
>a giant compare to us :(
Yes, that is right but most of us usually visit os development sites
and I think htat we have a fairly large chance of making it quite wide
used at least by "hobby os developers":)
Jens Olsson
>I am in agreement with a tag or signature in principle, it is just the space
>issue and that I do not like you El, is that a little L or what ? What does
>it mean and where did it come from ?
>
Well, EI was "Extended Id" but now we call the standard "Extended
Partition Type", so the EI thingy is not relevant any more.
Jens Olsson
already begun on it.
//Jens
On Sun, 11 Aug 2002 20:49:07 +0100, "Aaron Gray" <aaro...@beeb.net>
wrote:
-----------
Jens Olsson
http://hem.netlink.se/~sft3236/Extended Partition Type 2.pdf
//Jens
Stéphane Martineau
> Partition Type", so the EI thingy is not relevant any more.
I think it's still valid, if we use a tag i think it's a good one! As for
Extended
Partition Type it could be something else, Brian Bruinewoud suggested
to call it The "alt.os.development partition" or aodp for short. Sound
nice to me!
cr88192
> Here's the last update of our document:
>
> http://hem.netlink.se/~sft3236/Extended Partition Type 2.pdf
>
> //Jens
>
>
I came up with an idea: we could tag the pointer:
"FSID" followed by a pointer to the data block.
sorry, I just don't really like a fixed placed object at 0x196 because that
location could be annoying when writing a bootsector.
also for the data block I would consider a reference to a var/value type
system to be useful, but I am not sure how many people would actually need
this.
also calling it "fs name" would be ambiguous and might make people think of
the volume label or similar... "fs type" is a better name.
otherwise it is ok in my mind.
FYS
Hi Jens, Hi everyone.
I have returned. :)
I too have mixed feelings about the know efi partition release
by Intel and Microsoft, though I have not yet studied it intensely.
As for the current items you have Jens, and these are only my
opinions, do with them as you guys want:
1.)
page 4 (of 8), if the "Ben..." entry is me,
"Benjamin David Lunt"
please. :)
2.)
page 6 (of 8) section 2.3:
I would put the "un-fixed" sized name "FSName" at the
end of the structure so that the remaining items are in
a fixed place relative to the structure.
Then we can warrant the FSNameLen to be at least 1 and at
most (size-1-sizeof(structure to FSNameLen).
Since we have 512 bytes in a sector (standard for this
document?), we could add a few more entries since most
likely the name would not be (512-1-sizeof(struct)) in
length.
a. size of a sector: (byte)
(1 = 128), 2 = 512, 3 = 1024, 4 = 2048, etc.
Not necessarily needed for the FS, but to allow
the structure to know how many bytes were read in
the "read FS data block" code. If a sector is
1024 bytes long and we assume 512 always, there
are 512 bytes we could have used for other things
pertaining to this block.
( ** I guess the size field could be used here ** )
( though it would most likely be an actual number of
bytes, rather than 2,3,4, etc.)
( leave the size field a WORD, and make
it the size of a sector (512, 1024, 2048, etc.))
(again, just thoughts I am writing down on "paper".)
b. a date field
in the form of dd-mmm-yyyy(null)
dd = numerical two digit day 00 - 31
mmm = alpha three "digit" month "jan", "feb", etc.
(all lowercase)
yyyy = numerical four digit year (0000-9999)
(null) = an asciiz string terminator
or make it a 32-bit (64-bit) count of seconds since
a date in the past, say the day we make this
an a.o.d standard. :)
3.) the description for 2.3 has an ID sig of "EI"
and the structure is "EPT"...
4.) the CRC really doesn't have to be 32-bit does it?
with only 512 bytes (usually), wouldn't an 8-bit
"1's comp of sum of all bytes in block" work?
5.) this one is a little off, and may not be needed,
but would a byte field for the "nearest partition
type already available" be worth while. For instance,
if the new type was near "FAT-32" compatible, but
not quite, and the current operating system did
not support this new type of FS, would an "alternative"
FS type that is already defined be worth while?
I don't know if it would make it worth while. The
only thing I can think of where it would, would be
if the new FS was VFAT-12 and the OS that loaded
it was only FAT-12, then the alternative would
be the original FAT-12 file type.
Just a thought. Probably not even worth adding....
Anyway, these are just my opinions. I am not yet
completely sold on either this standard or the new efi
stuff. I just thought I would through in my two cents.
Thanks,
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Forever Young Software
http://www.cybertrails.com/~fys/index.htm
To reply by email, please remove the zzzzzz's
Batteries not included,
Some assembly required.
"Jens Olsson" <jens_s...@zekra.se> wrote in message
news:3d578968...@news.netlink.se...
Aaron Gray
that
> location could be annoying when writing a bootsector.
Don't you mean 0x1FD ?
Aaron
FYS
P.S. I haven't read all the posts yet, nor do I understand
what the 0x196 (or 0x1FD) reference in the MBR is for yet,
but I think (IMO), the only change to the MBR should be the
0x7F byte in the partition table entry.
If you modify the byte at 0x1FD, what if your 0x7F partition
entry is the last entry and it uses the lba size field?
I may be all wet here, so some explain if I am.
Stéphane Martineau
proposal.
You missed the name of:
Francis Rounds
Dark Fiber ?
Brian Bruinewood
Maybe we should ask all of them if they want their name to be in this
document, though.
Why 0x196 ? I cant remember this one being suggested in any posts ? Did I
miss something ? Aaron had proposed 0x1FC-0x1FD, just before the end
of the sector signature for a valid boot sector, sounded good to me.
Btw have you noticed that the sector/offset could be seem as just a 16 bits
offset in the first 64K of the partition. IMO we should threat it that way.
Just
divide (could be a shift of course) by the sector size.
You should also align all fields on their natural boundary (e.i. 32 bits for
32
bits fields, etc) Put the version field before the string, or use an offset
for
the string-id that way it's gonna make the size of the structure variable
in length. Following the string-id could also be a list of enviroment
null-terminated string. The list will end with another null.
We could drop the length of the string (isn't 16 bits a little bit over the
top).
I would prefer a maximum length of 63 or 127 characters for the string-id,
anyone ?
You should also add the reasons we have to make those choice and also
a list of other possibilities that we did consider (and are still under
consideration).
Also, I'm not sure if should have all those fields as mandatory. IMO it's
not
a problem for myself, but it could be for some people who have their name
in this document ???
I'm waiting for aaron proposal, but until then what about if we use the last
bit
of the first byte to tell between two format. One is simply a string-id, the
other is the full structure ?
Stéphane Martineau
> entry is the last entry and it uses the lba size field?
>
> I may be all wet here, so some explain if I am.
Nothing is change to the MBR structure. Everything is
in the partition itself.
cr88192
the spec I read had said 0x196. that is why I am complaining about it.
0x1FD would be fine with me, but I don't like anything arbitrary near the
middle of the sector as it would complicate positioning crap in the
bootsector around it... ok byte 406 is reasonably near the end, but still
it is in an annoying place.
if infact data is located near the end of the sector for some reason I
would like a field that could float around and hopefully be out of the
way...
FYS
"Stéphane Martineau" <sma...@mail.com.NOSPAM> wrote in message
news:LGT59.8207$GC6.2...@weber.videotron.net...
Hi everyone,
The pointer to the "ID" structure is actually in the boot
sector of the partition and not the MBR. This seems fine.
However, I still have a "problem" (question) with it's location.
I have seen Partition Tables in a partitions boot sector
pointing to other ("like") partitions. Would this be a problem
with pointers in and above 0x1BE?
If so, the "look for signature ID" may be in order or have the
pointer located at 0x1BE - 2.
Just my opinions.
Aaron Gray
> > that
> >> location could be annoying when writing a bootsector.
> >
> > Don't you mean 0x1FD ?
> >
> the spec I read had said 0x196. that is why I am complaining about it.
> 0x1FD would be fine with me, but I don't like anything arbitrary near the
> middle of the sector as it would complicate positioning crap in the
> bootsector around it... ok byte 406 is reasonably near the end, but still
> it is in an annoying place.
What is going on Jens ?
> if infact data is located near the end of the sector for some reason I
> would like a field that could float around and hopefully be out of the
> way...
What I am now thinking is we have a tagged block for the pointer that is
ideally in the bootsector and that is ideally at the end ...0FDh, but maybe
somewhere before so that if the signature is not located at the ideal fix
position then a search is made of the say first two sectors.
Aaron
Francis Rounds
> You should say on the first page that the document is a draft, and a
> proposal.
>
> You missed the name of:
> Francis Rounds
> Dark Fiber ?
> Brian Bruinewood
>
> Maybe we should ask all of them if they want their name to be in this
> document, though.
Oh, I'd love my name to be in there...makes me feel like an ISO official
:) Of course, if I don't contribute enough, feel free to leave me out.
Francis Rounds
KVP
> Here is the result of what everyone said in the
> thread "New Partition Type ID (Please vote!)".
> First, I want to say thank you to everyone that
> participated. And if you didn't, you can continue
> the conversation here.
> If i've mistaken what you said or what your choice
> was, just tell me and I will correct it.
I've read the specification, and I found it great, but
I have some additions for the proposed specifications.
> Here's the results:
> ======================================
> We've agreed on this:
> 1) The new partition type will be 0x7F and will be
> called the "extended partition type" or EPT for short.
> 2) At least a basic reference to the extended partition
> informations will be put into the first sector of the
> partition. While the informations itself can be inside
> the first sector or in other sectors if desired.
The pointer structure has a little endian byte format, but
a big endian bit format. Is this good? The msb of the offset
shouldn't be in the lsb of the sector... (maybe just a typo)
How about placing a two byte relative _byte_ offset into this field?
On filesystems with 512 byte sectors, this offset will fall into
two parts as proposed, but on other systems, you could have any
sector size, and still maintain the compatibility. (so it would be
just the number of bytes from the beginning of the boot sector)
> 3) The partition type will be a string. Even proposals
> for integer-id were used to store string-id :)
> ======================================
> What we need to agreed on:
> 1) Where the informations will be and what it will be:
> - I think it should be at a fixed location, no tag
> should be used, there's no need for them and they use
> bytes for no good reason. For now i'm voting for Jens
> Olsson proposal of using a sector/offset (2 byte) but
> without the tag which is NOT needed. I'm voting to put
> those two bytes at offset 508-509 (0x1FC-0x1FD)
> - Jens Olsson proposal add the tag "El", and i'm
> guessing there's no fixed location ?
> - Ayende Rahien essentialy seems to agree on
> everything Jens as proposed.
> - Aaron has many proposals, I guess I'm gonna let
> him clarify is position :)
> - The mysterious Mr. cr88192 :) seem to have opted
> for a tag that can be in the first xK of the
> partition. Anymore information about that ?
> 2) Should the string id be fixed of variable in
> length.
Variable, and be the last entry in the structure.
(so other datas could be addressed by a struct.)
> - I prefer variable in length, null-terminated
> and begin with a length-tag (a single byte).
> - Ayende Rahien seem to agree with that.
> - Aaron Grey want a variable string too.
> - Jens Olsson seem to want a fixed string length of
> 16 bytes.
> - A fixed string for cr88192 too (6 or 14 bytes)
> 3) Optional or mandatory fields/informations
> beside the partition type.
> - Myself, Aaron, Jens and Ayende seem to want
> that.
> - What about you cr88192 ?
> - OK, now we need some proposal for the format
> and the specification of that optional or/and
> mandatory informations. I'm pretty open-minded
> on that, so as long as there some flexibility
> into it I'll agree to just about anything.
> - Jens has already made a proposal, I've also
> added a bit to that proposal and i'm waiting
> for a specific Aaron proposal on this
> subject.
Best wishes: Viktor
cr88192
>> would like a field that could float around and hopefully be out of the
>> way...
>
> What I am now thinking is we have a tagged block for the pointer that is
> ideally in the bootsector and that is ideally at the end ...0FDh, but
> maybe somewhere before so that if the signature is not located at the
> ideal fix position then a search is made of the say first two sectors.
>
Aaron Gray
> I have seen Partition Tables in a partitions boot sector
> pointing to other ("like") partitions. Would this be a problem
> with pointers in and above 0x1BE?
>
> If so, the "look for signature ID" may be in order or have the
> pointer located at 0x1BE - 2.
These are not within the/our standard :) And are outside of the domain so
are uneffected. If someone wants to implement such a design within our
"system" which seems pointless, then we should go back to a tagged
signatured pointer block. But it is most likely that our partition would
reside as a sibling of such a structure, which should still function
correctly with our design. Providing the hosted OS deals with its own
partition details correctly.
Aaron
Aaron Gray
> >> would like a field that could float around and hopefully be out of the
> >> way...
> >
> > What I am now thinking is we have a tagged block for the pointer that is
> > ideally in the bootsector and that is ideally at the end ...0FDh, but
> > maybe somewhere before so that if the signature is not located at the
> > ideal fix position then a search is made of the say first two sectors.
> >
> that is sort of what I was talking about somewhere...
Yeah, I came round to the way you (lot) were originally thinking, mainly to
accomidate you lot, but the voting went the other way :)
Aaron
cr88192
I will define that there will be a structure which is variable location and
is referred to using a reference.
the reference is a 16 bit offset relative to the start of the partition. it
is also to be prefixed by the tag "FSID" which is to be aligned on a 32 bit
boundary.
ideally the tag will be located at 0x1F8 and consequently the reference at
0x1FC in sector 0, but may be moved if that location is not available for
some reason.
bit 15 of the reference will be reserved.
references will be left shifted 1 so all objects will be located on an
even boundary, and a value of 0 will indicate no object.
the structure referred to is a string chain. a string will have a 16 bit
next link, this will use bit 15 to indicate the presence of a child link
(which will directly follow the next link if present), bit 15 of the child
link will be reserved. after this/these will come the string which will be
in pascal syntax.
the first string will not have a variable, and will identify the fs type.
all other strings (including those in child groups) will have the syntax
of:
'variable=value' or 'variable' with a child group present.
cr88192
ok, a simplification:
the child reference and string are exclusive.
then:
each element has a 16 bit next link, which if bit 15 is set is followed by
a child link, otherwise it is followed by a pascal string.
the first element in each list will identify the list, with the fs type
conceptually being the name of the topmost list.
bit 15 of the initial pointer will indicate that it refers to a list
element, otherwise it refers to a pascal string with the fs type name.
this just seems cleaner in my mind...
Aaron Gray
Oh, some actual action :)
BTW. We were thinking that this "standards proceedure" will take a couple of
weeks, so the standard may vary over that time :)
Have fun :)
Aaron
FYS
"Aaron Gray" <aaro...@beeb.net> wrote in message
news:aj9a77$c7n$1...@news8.svr.pol.co.uk...
Hi Aaron,
Okay. First, I would like to say that if it is not yet "written
in stone", that I would like state that my vote would be to have
a "tagged signatured pointer block", i.e. you look for a small
signature throughout the boot block, rather than having it at
a set place.
However. Second, I do realise I came in to this discussion a
little late due to my absance, so either way will work for me. :)
Thanks,
Aaron Gray
> in stone", that I would like state that my vote would be to have
> a "tagged signatured pointer block", i.e. you look for a small
> signature throughout the boot block, rather than having it at
> a set place.
Things are very open still, what is going on is as you know we have had a
vote on a set of propositions for the design, put forward by Stephane. Jens
has drawn up a standard and is ammending it to the wishes of the majority,
this is the group design. Individuals are encoraged to put forward their own
designs if they do not like the group one and feel that it is "designed by
comittee" for example. I am putting together a set of premises for the
design, to help guide and check it, hopefully I should put this on line
soon. We are going to take a couple of weeks to the end of the month to
finalize the design or designs. Then we are going to take a vote on it.
> However. Second, I do realise I came in to this discussion a
> little late due to my absance, so either way will work for me. :)
If you feel strongly about anything then follow through on it, the floor is
open so to speak. This design has got to survive the test of time, "so the
more eyeballs the better". Read, critisise, and design is the moto :)
Aaron
Stéphane Martineau
> in stone", that I would like state that my vote would be to have
> a "tagged signatured pointer block", i.e. you look for a small
> signature throughout the boot block, rather than having it at
> a set place.
Nothing is fixed in stone, far from it.
I personally don't like the use of a tag since it's unecessary,
requiert a scan, should/must requiert a crc to be safe, could
use unecessary bytes in the first sector. Some agree with me,
some don't other don't care. I think my arguments are valid, but
I guess we will need a vote on this.
As for a fixed address, imo it should always be found at
sectorSize - 2 - sizeof (etpPtr).
ByrdKernel
wrong with the spec (other than the typical schizophrenia of lots of different
people with different ideas), but I just don't have the bandwidth to contribute
much. :)
ByrdKernel (Mike)
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
FYS
Hi Aaron, Stephane,
Thanks for the replies. I am just now catching up with all the
posts and what not. Just now getting a lot of the ideas that
were/are presented.
I was thinking that it was further along as a standard than
what it really is.
Thanks and I should be able to keep in touch now.
Jens, if you are reading this:
A standard is not a standard if there is not a "contact"
section :) Last I read, there was no way for a
"passer by" to contact the standard committee for
questions, revisions, etc.
Thanks,
Ben
"Aaron Gray" <aaro...@beeb.net> wrote in message
news:aj9j8m$rt$1...@newsg2.svr.pol.co.uk...
Jens Olsson
letter one (If we want a signature at all).
//Jens
-----------
Jens Olsson
>"FSID" followed by a pointer to the data block.
>
Actuall I came up with that idea on my first proposal but few seem to
want a tag.
Jens Olsson
>What is going on Jens ?
>
Yes, of course it should be 0x1FD:) Don't know why I wrote anything
else in the specs... I converted 509 from dec to hex in windows
calculator but I must have written it incorectly in the spec:)
Anyway, I have that fixed in the next one. These are only drafts
anyway.
//Jens
Jens Olsson
>However, I still have a "problem" (question) with it's location.
>I have seen Partition Tables in a partitions boot sector
>pointing to other ("like") partitions. Would this be a problem
>with pointers in and above 0x1BE?
>
Yes, but that is only on an extended partition, right? There is no
need for us to cover the extended partiions because there is only one
known such partition (which I know of that is:))
Jens Olsson
>Jens, if you are reading this:
>
>A standard is not a standard if there is not a "contact"
>section :) Last I read, there was no way for a
>"passer by" to contact the standard committee for
>questions, revisions, etc.
I agree with you but it's not published outside a.o.d yet and IIRC
someone where going to make some presentaion on the web for this and
there should probably be some where to contact us there. And then we
can put our URL on the spec. Anyway, I don't think there is any hurry,
or is there? I suppose I could always put an e-mail address on the
spec if anyone is interseted in being a temporary contact:)
//Jens
-----------
Jens Olsson
>Nothing is fixed in stone, far from it.
>
>I personally don't like the use of a tag since it's unecessary,
>requiert a scan, should/must requiert a crc to be safe, could
>use unecessary bytes in the first sector. Some agree with me,
>some don't other don't care. I think my arguments are valid, but
>I guess we will need a vote on this.
>
>As for a fixed address, imo it should always be found at
>sectorSize - 2 - sizeof (etpPtr).
>
it is certainly unnecessary but for those who use that part I am sure
they would love a tag so they don't have to redesign their whole file
system. For me there is no problem because I have no filesystem
variables in sector 0, everything is stored in 1 and 2 but for others
I think there can be a problem (I can be wrong though)
//Jens
Jens Olsson
//Jens
On Mon, 12 Aug 2002 18:12:20 -0700, ByrdKernel <byrdk...@yahoo.com>
wrote:
-----------
Jens Olsson
<sma...@mail.com.NOSPAM> wrote:
>You should say on the first page that the document is a draft, and a
>proposal.
Yes, that would probably be better. It will be there in the next draft
release.
>
>You missed the name of:
>Francis Rounds
>Dark Fiber ?
>Brian Bruinewood
Added
>
>Maybe we should ask all of them if they want their name to be in this
>document, though.
Yes, I thought I do that later but now I have written in the
documents, people in italic, please tell me whether you want to be
here or not, That would probably be sufficient you think?
>
>Why 0x196 ? I cant remember this one being suggested in any posts ? Did I
>miss something ? Aaron had proposed 0x1FC-0x1FD, just before the end
>of the sector signature for a valid boot sector, sounded good to me.
Yes that is wwhat it should be... and now ppl in other threads wrote
only 0x1FD... anyway.... its not that important yet because we are not
completely ready with the structure of the pointer block. some people
want a tag and some doesn't.... I think there should be a real vote on
that.
>
>Btw have you noticed that the sector/offset could be seem as just a 16 bits
>offset in the first 64K of the partition. IMO we should threat it that way.
Yes I have, and you are probably right, it may be easier to think of
it that way.
>Just
>divide (could be a shift of course) by the sector size.
>
>You should also align all fields on their natural boundary (e.i. 32 bits for
>32
>bits fields, etc) Put the version field before the string, or use an offset
>for
>the string-id that way it's gonna make the size of the structure variable
>in length. Following the string-id could also be a list of enviroment
>null-terminated string. The list will end with another null.
Yes I could do that but I also think it would be quite natural to have
the string first because, if I understand correctly it is the only
think we require to be present in the data structure.
>
>We could drop the length of the string (isn't 16 bits a little bit over the
>top).
>I would prefer a maximum length of 63 or 127 characters for the string-id,
>anyone ?
Yes, I certainly agree but my intention was to put the string 4 byte
aligned in memory, Ok its no big deal we could certainly use a 1 byte
instead.
>
>You should also add the reasons we have to make those choice and also
>a list of other possibilities that we did consider (and are still under
>consideration).
Ok,
>
>Also, I'm not sure if should have all those fields as mandatory. IMO it's
>not
>a problem for myself, but it could be for some people who have their name
>in this document ???
I thought we almost descided before that only the string id should be
mandatory. If one don't want any more than the string id they can set
the Size item to cut of the rest of the structure. (I am going to
write that later, I have that part of the doc under progress)
>
>I'm waiting for aaron proposal, but until then what about if we use the last
>bit
>of the first byte to tell between two format. One is simply a string-id, the
>other is the full structure ?
Ok
//Jens
Jens Olsson
Jens Olsson
>ideally the tag will be located at 0x1F8 and consequently the reference at
>0x1FC in sector 0, but may be moved if that location is not available for
>some reason.
>bit 15 of the reference will be reserved.
I have no opinion on the rest but I think that we should either have a
tag and it could be locatid in a range or we should not have a tag and
it should be locaed at a specific location. I only think this would
make the standard harder to follow, many ppl will probably only
support it if it is located at 0x1f( and won't add code to search for
it.
Jens Olsson
> The pointer structure has a little endian byte format, but
> a big endian bit format. Is this good? The msb of the offset
> shouldn't be in the lsb of the sector... (maybe just a typo)
>
> How about placing a two byte relative _byte_ offset into this field?
> On filesystems with 512 byte sectors, this offset will fall into
> two parts as proposed, but on other systems, you could have any
> sector size, and still maintain the compatibility. (so it would be
> just the number of bytes from the beginning of the boot sector)
>
I don't know, I think it works as is. The limitation is that you cant
use more than 512 bytes per sector to put the start of the data
structure in. I don't know wwhat will happen but it seem like we are
going to use a plain 16 bit byte pointer. Myself, I think the approach
in the spec is OK because it is easy to extract the sector and the
offset and just load it in. You will load it in 2 registers like AX
and BX for exambple and do AND AX, 0x1FF to get the offset into AX and
and SHR BX, 0x9 to get the sector. I don't know much about other
systems because I normaly use intel. I don't know if htere is a
problem.
Stéphane Martineau
> letter one (If we want a signature at all).
No, it's not a signature, but it could be a better name to
Extended Partition Type.
Stéphane Martineau
> it is certainly unnecessary but for those who use that part I am sure
> they would love a tag so they don't have to redesign their whole file
> system. For me there is no problem because I have no filesystem
> variables in sector 0, everything is stored in 1 and 2 but for others
> I think there can be a problem (I can be wrong though)
I've said many time that imo, those FS should be modified a little
bit if they want to use the specification. That kind of modification
should be trivial, if not then I'm guessing they already have choosen
their own partition type. The idea is to propose something new,
but maybe it's just me :)
Btw, if we finaly agree on a fixed position, what do you think about
saying that's it's location is at sectorSize - 2 - sizeof (etpPtr) ? Which
is 0x1FC for a 512 bytes sector with a two bytes eptPtr and 0x3FC
for a 1024 bytes sector (i heard those are relativly common
in some part of asia ?) That way the specification will be sector
size independant just like the valid boot sector signature ?
Stéphane Martineau
> that.
Yes, we will need many votes before the end. For now we should just put
all the suggestions with their arguments together in preparation for that
moment.
> Yes I could do that but I also think it would be quite natural to have
> the string first because, if I understand correctly it is the only
> think we require to be present in the data structure.
I agree, the string should be first at least if it's the only thing that is
present.
> >We could drop the length of the string (isn't 16 bits a little bit over
the
> >top).
> >I would prefer a maximum length of 63 or 127 characters for the
string-id,
> >anyone ?
> Yes, I certainly agree but my intention was to put the string 4 byte
> aligned in memory, Ok its no big deal we could certainly use a 1 byte
> instead.
IMO aligning a string is not as important as keeping fields aligned since
it's natural to access an 8 bits char string, 8 bits at a time. But no
matter
what it's always possible to align the string, just put the byte at
string offset - 1, assuming the offset will always be aligned of course.
> >Also, I'm not sure if should have all those fields as mandatory. IMO it's
> >not
> >a problem for myself, but it could be for some people who have their name
> >in this document ???
> I thought we almost descided before that only the string id should be
> mandatory. If one don't want any more than the string id they can set
> the Size item to cut of the rest of the structure. (I am going to
> write that later, I have that part of the doc under progress)
Well in your current specification we have a lot of field before the
string (signature (you made it 4 bytes by the way :), a size field (2
bytes),
a non-align 4 bytes crc :(, Major & Minor version, a the length of the
string. That seem like a lot for people that just want a string.
> >I'm waiting for aaron proposal, but until then what about if we use the
last
> >bit
> >of the first byte to tell between two format. One is simply a string-id,
the
> >other is the full structure ?
>
> Ok
It could look (this is just aproposal) a bit like this (i'm using C++):
typedef unsigned char byte;
union EPT {
struct {
byte lengthFlag;
char stringId[0];
};
struct {
byte flags;
byte size;
word version;
dword crc;
dword fsVersion;
word ofsStringId;
word ofsEnvStringsList;
};
};
I don't care about the name of the fields, this is just an
exemple.
It could work that way, if lengthFlag (or flags) bit 7 is 0,
then it's just a stringId with a length of lengthFlags & 0x7F
plus the null character (not part of the length, but it
should be mandatory imo)
Other flags bits could be reserved. A byte for size should
be enough and beside that's not a limit since another field
in the structure could be added to reference another
extended structure. I've keep your version fields the same
size as your proposal and i've align the crc on 4 bytes. I
also used an offset to locate the string id, that way we
can keep the structure fixed in size, i can remember at least
another person that ask for that.
Also, cr88192 has proposed to use a list of environment
strings, we either put that list after the string-id or use
another field to reference that list. In the exemple I've used
another field, but that's not really important.
Maybe we should add a creation date for the partition too ?
Stéphane Martineau
> tag and it could be locatid in a range or we should not have a tag and
> it should be locaed at a specific location. I only think this would
> make the standard harder to follow, many ppl will probably only
> support it if it is located at 0x1f( and won't add code to search for
> it.
I agree, should be one or the other, not both. I vote for a fixed
position :)
Stéphane Martineau
the structure fields should be byte packed.
FYS
"Jens Olsson" <jens_s...@zekra.se> wrote in message
news:3d58d8fc...@news.netlink.se...
> >
> >However, I still have a "problem" (question) with it's location.
> >I have seen Partition Tables in a partitions boot sector
> >pointing to other ("like") partitions. Would this be a problem
> >with pointers in and above 0x1BE?
> >
>
> Yes, but that is only on an extended partition, right? There is no
> need for us to cover the extended partiions because there is only one
> known such partition (which I know of that is:))
>
> //Jens
Hi Jens,
Most of the time, if at all, this is not a problem. However,
there has been a few times I have seen this.
If we had a signature block that could be anywhere in the boot
sector, it would allow the above.
However, it is not that important since it is rare to have
a self pointing partition, etc..
FYS
> >
> >Jens, if you are reading this:
> I read this group every day:)
>
> >
> >A standard is not a standard if there is not a "contact"
> >section :) Last I read, there was no way for a
> >"passer by" to contact the standard committee for
> >questions, revisions, etc.
> I agree with you but it's not published outside a.o.d yet and IIRC
> someone where going to make some presentaion on the web for this and
> there should probably be some where to contact us there. And then we
> can put our URL on the spec. Anyway, I don't think there is any hurry,
> or is there? I suppose I could always put an e-mail address on the
> spec if anyone is interseted in being a temporary contact:)
>
> //Jens
Na, it was just something to add to your notes, or
a title on some page:
"add contact info here"
See ya,
Ben
Mark & Candice White
I want to ID the partition but do not want to waste space.
Any solution that does this is fine with me.
To me the ideal is:
Fixed, small, number ID, and with a flag for the optional extra info.
I.E. At the end of the sector have:
[optional 16-bit offset for extra info][1-bit flag if offset present]
[1-bit checksum][14-bit ID] [AA55]
This will require only 2 bytes for those who want a small numerical ID.
It will also allow the extra info to be anywhere in the first 128 (512)
sectors. One ID can be set aside as the 'only identified by string'
type. This will conserve the number ID space as only those using numbers
only need numbers.
---------
Mark & Candice White
Stéphane Martineau
> It will also allow the extra info to be anywhere in the first 128 (512)
> sectors. One ID can be set aside as the 'only identified by string'
> type. This will conserve the number ID space as only those using numbers
> only need numbers.
Most peoples want a string-id. The problem with a small number-id is
that without a central authority to register them conflicts will be much
frequent, just think about two peoples wanting to use the same
number-id because it "looks cool".
If we use two bytes to locate the information inside the first 64k. The
first byte of that information can have it's bit 7 set to 1 if it's a
structure (see jens proposal) or zero if it's just a string-id. The
following
bytes will contain the string-id null terminated. That will add an overhead
of 4 bytes + the length of the string. That would mean 6 bytes for a very
short 2 letter string, 8 bytes for a short 4 letter string. Would'nt that be
satisfactory to you ?
I think we should only use one type of id, and a stirng-id is much more
flexible and have more advantages then an integer-id, at least imo!
cr88192
I like a simple string id, but have also been thinking of ad-hoc keys/trees
which could be used. my mind seems to be drifting off to a lisp style
encoding.
consider, the structure has 2 parts: cells and strings.
cells are 4 bytes and consist of 2 slots, the first points to some data and
the second points to the next cell in the list.
each reference is 16 bit, maybe this time using bit 0 to indicate it refers
to a cell, otherwise it refers to a string.
the strings are just ordinary pascal strings, except that they are aligned
on a 2 byte boundary.
the bootsector reference (whether tagged or not) is the same encoding and
either refers to a list or string.
if it is a string it is an fs type and if it is a list it follows the
convention that the first string is the fs type and all the following
strings are arguments.
arguments either have the form of 'var=value' or (var args...).
a person can have whatever arguments they want, thus they could have:
("EXT2" "MountPath=/usr/local") or whatever.
("EXT2" ("SomeGroup" "A" "B" "C"))
or whatever...
I do not believe this has too much space cost.
and the last few lines of a bootsector could still be:
fsid db 4, "MyFS", 0 ;padded to make even alignment
dw fsid-$$
dw 0xAA55
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Dark Fiber
<sma...@mail.com.NOSPAM> wrote:
>======================================
>
>Here is the result of what everyone said in the
>thread "New Partition Type ID (Please vote!)".
I dont know if I'm fussed with the idea of putting
information in the partition.
if its not my partition, i dont care whats in it.
i'm not going to mount/load it.
what was the main point of the partition type thing?
off the top of my head, this is what I wanted ;)
assumption, nice pc's (ie: non old dogs),
leave the entire first track (or cylinder?) blank
except for the MBR sector, the rest of the sectors
on the track are empty.
what I wanted was something like thiss (throwing
down loose ideas here).
have 1 entry in the MBR that covers the whole disk,
and use the next 16 sectors (8kb) for partition entries
(rather than just 4 entries in mbr, and ugly things like
extended, logical, bsd slice, etc).
so the 8kb is full of small structrues which just have a
16bit major filesystem enumeration, 16 bit minor FS enumeration
(eg: NT has 1 major, and several minor)
major/minor would be good for FFS(free) FFS(net) FFS(open)
etc and other FS types that currently have the same
FS number, yet are totally incompatible.
the first 4096 would be set aside for existing FS,
the remaning a land grad, with the range 0xF000-0xFFFF
development ID's. like PCI vendor/hw numbers..
something like
uint16 fs_major_enum
uint16 fs_minor_enum
128bit physical sector start
128bit physical sector end
uint8 flags (bootable/big|little endian)
every partition (like now) has a boot sector that deals with whatever
it needs to do (load a boot manager or whatever)
i want to aleviate the 4 primary partition scheme, and
the current 8bit FS enumeration thats littered with duplicates
taking it a step further, the very first partition could be a small
10mb? partition, that on there each OS drops a dynamic exec that
supports a set API (format/resize/check/etc), so all partitioning
is done by the master boot program, rather than each OS.
anyway.. enough crappy ideas. time for me to sleep..
-- Dark Fiber <yakum...@hotmail.com> --
[FAQ] Write Your Own Operating System
http://www.mega-tokyo.com/os
Roguelike News II
http://www.mega-tokyo.com/rlnews
Sarien Sierra AGI Emulator
http://www.mega-tokyo.com/sarien
3x3 Eyes Fanfiction Archive
http://www.mega-tokyo.com/pai
FYS
"Dark Fiber" <yakum...@hotmail.com> wrote in message
news:1g1jluosf1mim37t3...@4ax.com...
>
> assumption, nice pc's (ie: non old dogs),
> leave the entire first track (or cylinder?) blank
> except for the MBR sector, the rest of the sectors
> on the track are empty.
Hi Dark Fiber,
At first I was thinking something like this too.
However, it seemed that I was the only one (smile)
Most newer OS's leave the first cylinder blank anyway,
except for the MBR. This would leave 62 sectors free
for info.
When an OS wanted to know where it's and all other
partitions where, simply check a "signature" (7Fh)
in the first partition entry in the MBR (for backward
compatibility), and then if found, know that the
remaining sectors on the track contain info.
The other four entries could contain what ever
they wanted for backward compatibility.
Then a "7Fh" compatible OS would know to ignore
all partition entries and get info from the
remaining sectors on the cylinder.
I didn't think everyone wanted to take it this
far, so I pretty much gave it up.
However, as it is now, any proposals are accepted,
with a all-for-one vote at the end, so don't
give up. I may comment if you give a proposal.
See ya,
Mark & Candice White
>> This will require only 2 bytes for those who want a small numerical ID.
>> It will also allow the extra info to be anywhere in the first 128 (512)
>> sectors. One ID can be set aside as the 'only identified by string'
>> type. This will conserve the number ID space as only those using numbers
>> only need numbers.
>
> Most peoples want a string-id. The problem with a small number-id is
> that without a central authority to register them conflicts will be much
> frequent, just think about two peoples wanting to use the same
> number-id because it "looks cool".
Could we not have a central authority to register them?
We are moving more toward a distributed infomation set for aod/osd,
would this be too hard for us to do?
> If we use two bytes to locate the information inside the first 64k. The
> first byte of that information can have it's bit 7 set to 1 if it's a
> structure (see jens proposal) or zero if it's just a string-id. The
> following
> bytes will contain the string-id null terminated. That will add an
> overhead of 4 bytes + the length of the string. That would mean 6 bytes
> for a very short 2 letter string, 8 bytes for a short 4 letter string.
> Would'nt that be satisfactory to you ?
>
> I think we should only use one type of id, and a stirng-id is much more
> flexible and have more advantages then an integer-id, at least imo!
For those not reading every post please break down for us as you
go along WHERE these bytes are. To me it is the ones in the first
sector I really care about. Is it 2 in sector 0, 1(flags) X(string-id)
1(null) anywhere of my choosing in the first 64k?
If it is only 2 bytes in the 0 sector, it passes my basic test of
being small.
Just so we think about it: What is to stop there being several 'MyFS'
out there. I have seen many 'MyOS' projects.... Some central authority
to register them will be needed at some point any way.
Chris Fallin
> Could we not have a central authority to register them? We are moving
> more toward a distributed infomation set for aod/osd, would this be too
> hard for us to do?
I liked the idea of using URLs, I think someone mentioned that earlier.
This gives a global namespace. Like: my-os.org/fast_fs/1.4
--
Chris Fallin
Email: ch...@cfallin.org
AIM : ProgrammerNerd1
URL : http://www.cfallin.org/
ByrdKernel
> Most peoples want a string-id. The problem with a small number-id is
> that without a central authority to register them conflicts will be much
> frequent, just think about two peoples wanting to use the same
> number-id because it "looks cool".
Then how about emphasizing everywhere that the numeric ID is mentioned that THIS
IS THE PLACE (insert URL here) to register your Extended Partition ID. :)
Jens Olsson
name....
//Jens
-----------
Jens Olsson
>I've said many time that imo, those FS should be modified a little
>bit if they want to use the specification. That kind of modification
>should be trivial, if not then I'm guessing they already have choosen
>their own partition type. The idea is to propose something new,
>but maybe it's just me :)
>
>Btw, if we finaly agree on a fixed position, what do you think about
>saying that's it's location is at sectorSize - 2 - sizeof (etpPtr) ? Which
>is 0x1FC for a 512 bytes sector with a two bytes eptPtr and 0x3FC
>for a 1024 bytes sector (i heard those are relativly common
>in some part of asia ?) That way the specification will be sector
>size independant just like the valid boot sector signature ?
>
Maybe good or maybe bad. The good thing is that it is always at the
end of the sector.... bad thing is that you have to know the sector
size in order to find the pointer.
Jens Olsson
>Hi Jens,
>
>Most of the time, if at all, this is not a problem. However,
>there has been a few times I have seen this.
>
>If we had a signature block that could be anywhere in the boot
>sector, it would allow the above.
Yes, I agree.
>
>However, it is not that important since it is rare to have
>a self pointing partition, etc..
Maybe it is, I don't know:) I thrust you:)
>
>Ben
Jens Olsson
<sma...@mail.com.NOSPAM> wrote:
>> want a tag and some doesn't.... I think there should be a real vote on
>> that.
>
>Yes, we will need many votes before the end. For now we should just put
>all the suggestions with their arguments together in preparation for that
>moment.
>
>
>> Yes I could do that but I also think it would be quite natural to have
>> the string first because, if I understand correctly it is the only
>> think we require to be present in the data structure.
>
>I agree, the string should be first at least if it's the only thing that is
>present.
Good:)
>
>
>> >We could drop the length of the string (isn't 16 bits a little bit over
>the
>> >top).
>> >I would prefer a maximum length of 63 or 127 characters for the
>string-id,
>> >anyone ?
>> Yes, I certainly agree but my intention was to put the string 4 byte
>> aligned in memory, Ok its no big deal we could certainly use a 1 byte
>> instead.
>
>IMO aligning a string is not as important as keeping fields aligned since
>it's natural to access an 8 bits char string, 8 bits at a time. But no
>matter
>what it's always possible to align the string, just put the byte at
>string offset - 1, assuming the offset will always be aligned of course.
>
>
>
>> I thought we almost descided before that only the string id should be
>> mandatory. If one don't want any more than the string id they can set
>> the Size item to cut of the rest of the structure. (I am going to
>> write that later, I have that part of the doc under progress)
>
>Well in your current specification we have a lot of field before the
>string (signature (you made it 4 bytes by the way :), a size field (2
>bytes),
>a non-align 4 bytes crc :(, Major & Minor version, a the length of the
>string. That seem like a lot for people that just want a string.
I thought the size field should be used so one can chose how many of
our optional fields to use. If we for example have in our structure
(only eample:)) a string, a long and a long one could set the length
to the end of thes string in order to use the string only.
Yes you are right, the crc is non-aligned but the plan is to put all
aligned at the end. the CRC must be there too to make sure that it is
a valid structure and it will probably a 1 byte crc or something
anyway if I understand ppl correctly.version is to make sure that we
have the option of making new things with our standard.
Yes, its some more data, but ppl can put it where they like so....
Maybe it is a problem, i am not sure.
>
>It could look (this is just aproposal) a bit like this (i'm using C++):
>
>typedef unsigned char byte;
>
>union EPT {
> struct {
> byte lengthFlag;
> char stringId[0];
> };
> struct {
> byte flags;
> byte size;
> word version;
> dword crc;
> dword fsVersion;
> word ofsStringId;
> word ofsEnvStringsList;
> };
>};
Well, that could be ok, I don't like unions because many programming
languages don't support them (it is possible to think of it as 2
structures instead so it is more clear for ppl not using C). anyway,
if we use this we need a way to determine which is used, lige a format
filed where 0 = length+string and 1 = flags, size, version, crc....
Another thing, using only the
struct {
byte lengthFlag;
char stringId[0];
};
thingy would not be sufficient since wwe have no signature in the
pointer block and none in the data block hich means that we have NO
way to check whenever a file system supports our standard. the pointer
block can be garbage and send us to a random sector, offset where we
find more garbage and we can't determine if it is garbage or data.
>
>I don't care about the name of the fields, this is just an
>exemple.
>
>It could work that way, if lengthFlag (or flags) bit 7 is 0,
>then it's just a stringId with a length of lengthFlags & 0x7F
>plus the null character (not part of the length, but it
>should be mandatory imo)
Ok there you have the solution to wwhich structure to be used (I
should have read all of it:))
>
>Other flags bits could be reserved. A byte for size should
>be enough and beside that's not a limit since another field
>in the structure could be added to reference another
>extended structure. I've keep your version fields the same
>size as your proposal and i've align the crc on 4 bytes. I
>also used an offset to locate the string id, that way we
>can keep the structure fixed in size, i can remember at least
>another person that ask for that.
>
>Also, cr88192 has proposed to use a list of environment
>strings, we either put that list after the string-id or use
>another field to reference that list. In the exemple I've used
>another field, but that's not really important.
Ok
>
>Maybe we should add a creation date for the partition too ?
Yes but I don't know what it can be used for. Isn't there already a
creation date of the root directory in most fiels systems?
Stéphane Martineau
> Maybe good or maybe bad. The good thing is that it is always at the
> end of the sector.... bad thing is that you have to know the sector
> size in order to find the pointer.
I don't understand how anyone would access a device without knowing
it's characteristic. If you read a sector from a disk and you don't know
it's size how do you know how much memory you'd need to store it ?
Stéphane Martineau
> our optional fields to use. If we for example have in our structure
> (only eample:)) a string, a long and a long one could set the length
> to the end of thes string in order to use the string only.
A single bit would do the job, peoples that only want a simple id has
expressed concerns about that much data. I's not a problem with me,
but imo we should take that into account. Another vote probably :)
> Yes you are right, the crc is non-aligned but the plan is to put all
> aligned at the end. the CRC must be there too to make sure that it is
> a valid structure and it will probably a 1 byte crc or something
> anyway if I understand ppl correctly.version is to make sure that we
> have the option of making new things with our standard.
IMO, a crc is only necessary if we use a tag. Without a tag I think
we should not impose it to peoples that only want a single id. For
a larger structure I think it should be there since it's never a bad
thing, and should be 32 bits like you did.
> Well, that could be ok, I don't like unions because many programming
> languages don't support them (it is possible to think of it as 2
> structures instead so it is more clear for ppl not using C).
Of course, it doesn't matter!
> Yes but I don't know what it can be used for. Isn't there already a
> creation date of the root directory in most fiels systems?
Of course it's not vital, the idea is just to standardize the way to
extract informations from EPT/AOD partitions. I think it
could be a useful field ? But it could also be a named attribute
like cr88192 proposed, something like
"CreationDate=99/99/9999 99:99:99".
Stéphane Martineau
Who would do it ? Will that person decide to make peoples pay when it
don't want to do it anyore ? How will conflicts be solved ? I think it's
much simpler without a central authority. Also with string id you
can still display the type of the partition even if you don't know what it
is, beside nearly everyone have voted for a string-id. But we'll see!
> For those not reading every post please break down for us as you
> go along WHERE these bytes are. To me it is the ones in the first
> sector I really care about. Is it 2 in sector 0, 1(flags) X(string-id)
> 1(null) anywhere of my choosing in the first 64k?
If we use a fixed location (my choice) it's currently two bytes. This
is an offset into the first 64K of the partition where the string-id
or a more sophisticated structure is located. The location can be in
the first sector or in any of the first 128 sectors assuming those are
512 bytes in length.
This seem to be the way we are going right now. Virtually
everyone have either agreed or have no problem with that. But
nothing is final.
> Just so we think about it: What is to stop there being several 'MyFS'
> out there. I have seen many 'MyOS' projects.... Some central authority
> to register them will be needed at some point any way.
Absolutly no one, those peoples will just have to live with their choice,
they'll decide that with themself, one or both could change their name
or they'll both act like idiotd and use the same id no matter what. Too
bad for them, then! One person has suggested to use an url and
register it, could be a good choice just like anything else.
Someone can try to keep track of all the names that will be in use,
but registering or worse reserving them should not be done except
if you like having trouble.
The idea is just to offer a nice solution to peoples of aod that need
a new partition type. IMO, we should not try to do much more
then that.
Stéphane Martineau
> This gives a global namespace. Like: my-os.org/fast_fs/1.4
Yes, it's a good choice. I don't think it should be mandatory, though!
Stéphane Martineau
that THIS
> IS THE PLACE (insert URL here) to register your Extended Partition ID. :)
IMO registering id is just asking for trouble. And beside string-id has
major
advantages against integer-id, so it's not an arbitrary choice. And the
majority
did vote to use them. You could use a two or a four letter string-id if you
want
to keep it short.
Anyway, maybe we should put that on a vote again (a final one this time),
anyone ?
Tim Robinson
| IMO registering id is just asking for trouble. And beside string-id
| has major
| advantages against integer-id, so it's not an arbitrary choice. And
| the majority
| did vote to use them. You could use a two or a four letter string-id
| if you want
| to keep it short.
IMO string IDs are just as unmanageable as integer IDs. You've still got the
problem of two people using "MyAmazingFileSystem" as you have of two people
using 0x1337. The only sure way to get around this problem, without having a
central registry, is to use an ID space so big (e.g. a 128-bit GUID) that
the chances of anyone's IDs collinding within the lifespan of the universe
are zero.
--
Tim Robinson
http://www.themoebius.org.uk/
cr88192
>> Okay. First, I would like to say that if it is not yet "written
>> in stone", that I would like state that my vote would be to have
>> a "tagged signatured pointer block", i.e. you look for a small
>> signature throughout the boot block, rather than having it at
>> a set place.
>
> Nothing is fixed in stone, far from it.
>
> I personally don't like the use of a tag since it's unecessary,
> requiert a scan, should/must requiert a crc to be safe, could
> use unecessary bytes in the first sector. Some agree with me,
> some don't other don't care. I think my arguments are valid, but
> I guess we will need a vote on this.
>
> As for a fixed address, imo it should always be found at
> sectorSize - 2 - sizeof (etpPtr).
I had been busy and was not really keeping up.
under my plan that would be the normal location, so in most cases a
comparison with the tag will verify that the pointer is in place.
otherwise it could float around somewhere in sector 0.
with tagging the last few lines of a boot sector would look like:
dd "FSID"
dw pointer_to_structure
dw 0xAA55
in my mind since the tag value would need to be correct, and if it is
located at the end of the sector I would think it safer than a lone pointer.
maybe the statement: unless it is not possible to locate it at 0x1F8 it is
to be located there.
the amount of bytes required for this tag is minimal, certainly smaller
than the purposed structure. also I like the idea of cramming everything in
the boot sector as well so I still want small structures.
if it is really important the tag could be made smaller, ie: 'TE'/'EI'/...
I am also in favor of structures that will unlikely need change, thus I
inherently distrust c style structures (new stuff requires change, usually
change involves changing the structure or hacking crap into fields, ...).
a minor extension to my list idea is that some "type flags" could be used
on the variables to indicate binary values, ie:
db 15, "TimeStamp$="
dd current_time
or something...
sure var names are bloaty but I figure that vars will not often be used,
more terse names could be used to save space:
"TS$=" for time stamp and similar...
cr88192
sadly often when accessing devices in many os's the sector size is hidden
away and has to be accessed via ioctl's.
in such systems usually the device is viewed as a file, or uses a virtual
sector size.
another way is to search for the 0xAA55 tag...
Stéphane Martineau
I do not agree, first they offer a much wider range of good/cool
values to peoples. And choosing one is easy, this is not the case
with integer-id. Do you take 1,2 or 3 or 4, or 5, what's the next
one that is free ?
> You've still got the problem of two people using
> "MyAmazingFileSystem" as you have of two people
> using 0x1337.
The idea is not to completly solve the problem, it's just to
make it less of a problem.
> The only sure way to get around this problem, without having a
> central registry, is to use an ID space so big (e.g. a 128-bit
> GUID) that > the chances of anyone's IDs collinding within the
> lifespan of the universe are zero.
That was/is my choice if we use an non string-id, and in the voting
thread that was the choice of virtually everyone if we were to
choose a non string-id. But virtually everyone choose a string-id
over that and some people even said that they will put a string
into the guid space :(
Beside with a string-id nothing will stop you from adding a
guid to it,
"whatever.{3296982E-FE09-4581-8BBA-1C46729F0C95}"
you get ultimate flexibility. IMO string-id look like the easiest
acceptable choices to most peoples, even for the one where
it's not their first choice.
Stéphane Martineau
Better, don't use one ;)
> a minor extension to my list idea is that some "type flags" could be used
> on the variables to indicate binary values, ie:
> db 15, "TimeStamp$="
> dd current_time
Would be fine with me!
Maxim S. Shatskih
> it's characteristic. If you read a sector from a disk and you don't
know
> it's size how do you know how much memory you'd need to store it ?
Sector sizes can be retrieved at IDE or SCSI level.
Max
Stéphane Martineau
> away and has to be accessed via ioctl's.
That ioctl service "should" always exist for block device. But you're right,
it might not always be available.
> another way is to search for the 0xAA55 tag...
Btw, do you know if 0xAA55 should be at the end of the sector
or it's assume to always be at 0x1FE no matter what ?
cr88192
>> sadly often when accessing devices in many os's the sector size is hidden
>> away and has to be accessed via ioctl's.
>
> That ioctl service "should" always exist for block device. But you're
> right, it might not always be available.
>
yep, or sometimes people just want to use the formatter on a raw file or
don't want to dirty their code by using system ioctl's.
also many fs designers don't really want to worry about sector size either
except if it will effect performance (partial sector reads). quite often
the logical sector size is much larger than the physical one anyways (1KiB
and 4KiB are common...).
few actually use 512 byte sectors, though one could to increase packing
efficiency (possibly reducing performance). I would think if implemented
properly this would have little effect for spans based filesystems at
least...
>
>> another way is to search for the 0xAA55 tag...
>
> Btw, do you know if 0xAA55 should be at the end of the sector
> or it's assume to always be at 0x1FE no matter what ?
from what I have read it is supposed to be at the end of the sector
regardless of sector size, however the sectors are nearly allways 512 bytes.
it is likely that many formaters would place it at 0x1FE based on an
assumption of the sector size.
I may be wrong though...
cr88192
>> IMO string IDs are just as unmanageable as integer IDs.
>
> I do not agree, first they offer a much wider range of good/cool
> values to peoples. And choosing one is easy, this is not the case
> with integer-id. Do you take 1,2 or 3 or 4, or 5, what's the next
> one that is free ?
>
>
>> You've still got the problem of two people using
>> "MyAmazingFileSystem" as you have of two people
>> using 0x1337.
>
> The idea is not to completly solve the problem, it's just to
> make it less of a problem.
>
>
>> The only sure way to get around this problem, without having a
>> central registry, is to use an ID space so big (e.g. a 128-bit
>> GUID) that > the chances of anyone's IDs collinding within the
>> lifespan of the universe are zero.
>
> That was/is my choice if we use an non string-id, and in the voting
> thread that was the choice of virtually everyone if we were to
> choose a non string-id. But virtually everyone choose a string-id
> over that and some people even said that they will put a string
> into the guid space :(
>
well, I take that back now...
my argument against guid's now is that you need some way to get the mac
address of the network card.
I before had another idea for unique number generation but the problem is
that it would only work if you had a unique number to start with.
this would require a repository to occasionally give out unique numbers to
use as seeds. luckily my magic algo could allow someone also to gain seed
numbers from other sources which had a valid seed to begin with as well.
an annoyance was that the numbers were variable length byte strings, and
after a while the generated numbers would eventually become larger...
getting seeds from increasingly less centralized sources would also yeild
longer seeds, which would be a problem.
in either algo without a unique number (either a mac or a seed) the algo is
uneffective.
> Beside with a string-id nothing will stop you from adding a
> guid to it,
> "whatever.{3296982E-FE09-4581-8BBA-1C46729F0C95}"
> you get ultimate flexibility. IMO string-id look like the easiest
> acceptable choices to most peoples, even for the one where
> it's not their first choice.
this would nearly force uniqueness.
in a world of strings it is less likely that multiple people will use the
same name, as oddly people seem reasonably good at this (except with human
names where people just can't really seem to be very original).
Stéphane Martineau
is
> uneffective.
Yep, but if you need a guid for your file system just use any guid generator
on any os that can generate them, like windows.
Maxim S. Shatskih
use the
> same name, as oddly people seem reasonably good at this (except with
human
> names where people just can't really seem to be very original).
Lot's of people will choose "MyFS", for instance.
GUIDs are better, since a) they are the same size - lesser parsing b)
guaranteed to be unique.
Max
Jens Olsson
>A single bit would do the job, peoples that only want a simple id has
>expressed concerns about that much data. I's not a problem with me,
>but imo we should take that into account. Another vote probably :)
>
>
>> Yes you are right, the crc is non-aligned but the plan is to put all
>> aligned at the end. the CRC must be there too to make sure that it is
>> a valid structure and it will probably a 1 byte crc or something
>> anyway if I understand ppl correctly.version is to make sure that we
>> have the option of making new things with our standard.
>
>IMO, a crc is only necessary if we use a tag. Without a tag I think
>we should not impose it to peoples that only want a single id. For
>a larger structure I think it should be there since it's never a bad
>thing, and should be 32 bits like you did.
Yes but we ened a way to check if it is EPT compatible and without a
tag I think crc is the way to go. Both would be best I think.
>
>
>Of course, it doesn't matter!
Right
>
>
>> Yes but I don't know what it can be used for. Isn't there already a
>> creation date of the root directory in most fiels systems?
>
>Of course it's not vital, the idea is just to standardize the way to
>extract informations from EPT/AOD partitions. I think it
>could be a useful field ? But it could also be a named attribute
>like cr88192 proposed, something like
>"CreationDate=99/99/9999 99:99:99".
Yes, maybe many of the fields should be named. I think using something
like RIFF would be nice.
Jens Olsson
>go along WHERE these bytes are. To me it is the ones in the first
>sector I really care about. Is it 2 in sector 0, 1(flags) X(string-id)
>1(null) anywhere of my choosing in the first 64k?
>
>If it is only 2 bytes in the 0 sector, it passes my basic test of
>being small.
>
>Just so we think about it: What is to stop there being several 'MyFS'
>out there. I have seen many 'MyOS' projects.... Some central authority
>to register them will be needed at some point any way.
>
One easy way would be to require ppl to put some info on-line and a
google search could work to verify that a ID is free (just a thought)
//Jens
Jens Olsson
>I liked the idea of using URLs, I think someone mentioned that earlier.
>This gives a global namespace. Like: my-os.org/fast_fs/1.4
I like this too actually!
//Jens
>
>--
>Chris Fallin
>Email: ch...@cfallin.org
>AIM : ProgrammerNerd1
>URL : http://www.cfallin.org/
-----------
Jens Olsson
<sma...@mail.com.NOSPAM> wrote:
>> Could we not have a central authority to register them?
>
>Who would do it ? Will that person decide to make peoples pay when it
>don't want to do it anyore ? How will conflicts be solved ? I think it's
>much simpler without a central authority. Also with string id you
>can still display the type of the partition even if you don't know what it
>is, beside nearly everyone have voted for a string-id. But we'll see!
One simple way is to put up a simple perl/php/asp/cf script to handle
it all and we can just relax:)
>
>If we use a fixed location (my choice) it's currently two bytes. This
>is an offset into the first 64K of the partition where the string-id
>or a more sophisticated structure is located. The location can be in
>the first sector or in any of the first 128 sectors assuming those are
>512 bytes in length.
>
>This seem to be the way we are going right now. Virtually
>everyone have either agreed or have no problem with that. But
>nothing is final.
Yes an we can shift the pointer a few steps, maybe 2 and gain 128*4 of
the first sectors instead which someone mentioned (don't remember who)
//Jens
cr88192
>> in a world of strings it is less likely that multiple people will
> use the
>> same name, as oddly people seem reasonably good at this (except with
> human
>> names where people just can't really seem to be very original).
>
> Lot's of people will choose "MyFS", for instance.
>
it could be written that such conventions are highly discouraged.
> GUIDs are better, since a) they are the same size - lesser parsing b)
> guaranteed to be unique.
>
they can not be generated without a mac address.
actually it could allways be possible to ask ieee for "virtual" mac
addresses though...
pretty lame is that the guid solves another misc technical problem of
mine as well, namely the generation of globally unique shared segid's.
nevermind...
Stéphane Martineau
Too bad for them!
> GUIDs are better, since a) they are the same size - lesser parsing b)
> guaranteed to be unique.
Nothing will ever stop "idiots" to use their own "invalid" guid to store
a "cool" value or a string, fact is peoples can do whatever they want.
Like I said, just put a guid as part of the string-id if you want. With
a string you get the best of everything with a single solution.
Maxim S. Shatskih
b)
> > guaranteed to be unique.
> >
> they can not be generated without a mac address.
Only the inventor of the new FS will generate a GUID for them, and he
can be supposed to have a MAC address.
Neither format/newfs nor mount will generate GUIDs.
Max
Maxim S. Shatskih
store
> a "cool" value or a string, fact is peoples can do whatever they
want.
This is really an idiocy. On MS platform, GUIDs are of very wide use,
and I never heard of any person who will do this idiocy instead of
running UUIDGEN.
The MSVC's wizards also invent the correct GUIDs.
Max
cr88192
> Only the inventor of the new FS will generate a GUID for them, and he
> can be supposed to have a MAC address.
> Neither format/newfs nor mount will generate GUIDs.
>
cr88192
>>Of course it's not vital, the idea is just to standardize the way to
>>extract informations from EPT/AOD partitions. I think it
>>could be a useful field ? But it could also be a named attribute
>>like cr88192 proposed, something like
>>"CreationDate=99/99/9999 99:99:99".
> Yes, maybe many of the fields should be named. I think using something
> like RIFF would be nice.
>
could also be 8 or 16 bit. I don't know...